This article was originally published on LinkedIn.

For years, I built custom software for small businesses. The work was personal and direct — sitting across the table from an owner, learning how their business actually ran, and translating that into code. I handled everything: requirements, database design, application logic, user experience. Each project started clean, built exactly for the way that client operated.

Then one of my long-time customers grew — and grew fast. Through a merger and acquisition, they went from being a regional operation to a multi-entity business almost overnight. Neither of their existing systems could handle the new scale or complexity. They needed to consolidate operations, unify their financials, and run the combined business on a single, dependable platform.

We evaluated several ERP options. What ultimately pushed us toward NetSuite was its promise of extensibility — the idea that you could start with a proven foundation and then shape it to fit your organization. That flexibility mattered, because this client wasn't starting from scratch. They already had years of custom tools, specialized workflows, and data models that reflected how they did business.

When I first stepped into NetSuite, I wasn't sure where I fit in. It was unlike anything I had worked with before: vast, structured, and deeply integrated. Everything connected to everything else — CRM, accounting, inventory, purchasing — but it was clear that the real value of NetSuite wasn't just in what it could do out of the box. It was in how it could be customized, enhanced, and extended to reflect the business itself.

And that's where things got interesting.

Because while NetSuite could handle most of the core processes, there were systems my client had built over the years — systems that embodied the company's "secret sauce." They couldn't simply be replaced. Those systems had to integrate seamlessly with NetSuite.

So, the focus shifted. It wasn't just about learning NetSuite's features; it was about understanding how to bend and extend it without breaking the underlying structure. Customization and integration weren't optional — they were essential.

That experience fundamentally changed how I viewed enterprise systems. What began as an attempt to adapt to a new platform became a deeper education in how large-scale software actually lives and breathes inside a business.

Patience — Learning to Live Inside the System

Once we made the move to NetSuite, my first challenge was simply getting my bearings. I had spent years building systems from scratch — designing every table, every interface, every workflow — and suddenly I was inside an environment that already did everything, but in its own very particular way.

So I started where any developer should: by learning how it actually works. I spent time using the product the way the client's employees did — navigating records, running reports, processing transactions. I wanted to understand the system from the user's perspective before I wrote a single line of code.

Then I dove into the backend. That's where the real learning curve began. Understanding NetSuite's data model — the relationships between entities, records, and transactions — took time. So did figuring out how SuiteScript fit into the picture, and how its APIs mapped to the system's internal logic.

For someone used to traditional database development, switching to SuiteScript was a leap. It's JavaScript-based, but not quite like writing JavaScript in the browser or on Node.js. It has its own patterns, quirks, and constraints. The concepts were familiar, but the execution often wasn't.

Over time, though, it started to click. I found myself appreciating the structure, the patterns, and the discipline that NetSuite imposed. It forced me to slow down, to be deliberate. Learning how to use RESTlets — one of the SuiteScript script types — was a turning point. RESTlets opened up the ability to build custom integrations and extend functionality in ways that weren't possible through the standard UI. That capability became critical, and in the long run, it paid off.

Then came SuiteQL — and for me, that changed everything. After years of working with SQL in other systems, having a true query language inside NetSuite finally felt like home. It provided a familiar, structured way to access and analyze data without fighting the system. SuiteQL was a game changer — not just technically, but mentally. It bridged the gap between the world I came from and the one I was learning to navigate.

In the end, patience was the key. NetSuite didn't reveal itself all at once; it had to be learned layer by layer. I came to like it — even the parts that frustrated me at first — and I learned to live with its peculiarities. Over time, I found my place in the ecosystem and, more importantly, discovered where I could add real value to businesses running on it.

Persistence — Working the System, and Beyond It

Once I understood the fundamentals of how NetSuite worked, the next challenge was figuring out how to actually work with it. That took persistence — a kind of steady, methodical commitment that isn't about intensity so much as endurance.

When you build software from scratch, persistence usually means debugging your own mistakes. But in NetSuite, it often means learning how to navigate someone else's logic — Oracle's, the client's, or the thousands of developers and administrators who have customized their systems before you. It's a constant negotiation between what you want to do and what the system will let you do.

There were moments early on when I was tempted to push back against that structure — to build around NetSuite instead of within it. But over time, I learned that progress comes from understanding and respecting the system's boundaries. In a platform as interconnected as NetSuite, there's rarely a truly "isolated" change. Every workflow, script, and field exists in a larger web of dependencies. Touch one thing, and something else inevitably reacts.

Persistence meant developing a rhythm. Experiment, test, document, repeat. It meant accepting that a single integration or customization might take multiple iterations to get right — not because the goal was unclear, but because the system's logic had to be understood and aligned with. Some things that seemed impossible on day one revealed themselves to be completely doable once I looked at them through NetSuite's lens instead of my own.

But what really changed things for me was realizing that I didn't have to choose between working within NetSuite and working outside of it. I started developing external applications — web, mobile, desktop, even console-based tools — that connected to NetSuite through its APIs and RESTlets. These systems handled the specialized functions that NetSuite couldn't, while still feeding data back into the platform to keep everything in sync.

A big part of that success came from leveraging my experience with Xojo — my not-so-secret weapon. Xojo's cross-platform capabilities let me rapidly prototype and deploy applications that interacted directly with NetSuite. Over the years, I've written about that approach, given webinars on it, and shared examples of how external Xojo apps can complement and extend NetSuite in powerful ways. It became the bridge between my background in custom development and my work inside the Suite — a way to apply everything I'd learned in one world to make the other stronger.

That hybrid approach — combining the discipline of working inside the framework with the creativity of building outside of it — became the key to real success. It let me give clients the best of both worlds: the stability of a proven ERP and the flexibility of custom-built tools.

In the end, persistence wasn't just about learning how to survive inside NetSuite. It was about learning when to step outside of it — and how to connect those two worlds in ways that made the whole system stronger.

Pragmatism — Designing for the Real World

The deeper I got into NetSuite, the more I began to appreciate that success in this space isn't about building the most elegant solution. It's about building the right one — the one that works reliably, that people can actually use, and that won't break the moment something upstream changes.

In the early days of my career, I was obsessed with clean design — carefully normalized databases, perfectly abstracted code, intuitive UIs. That approach worked beautifully when I controlled every piece of the system. But inside NetSuite, or any enterprise platform, that kind of purity just isn't practical. These systems live in the real world — full of exceptions, legacy processes, compliance requirements, and human behavior that doesn't always make sense on paper.

Pragmatism, for me, meant shifting my mindset. It meant realizing that a solution doesn't need to be "perfect" to be effective. Sometimes the right answer is a saved search that gets emailed nightly instead of an API-driven dashboard. Sometimes it's a manual approval step that prevents a costly mistake. And sometimes it's knowing when not to automate something — because the process itself still needs to evolve before it's worth hardcoding.

I also learned that pragmatism extends beyond code. It's about designing systems that reflect how the business actually runs, not how I think it should run. It's about understanding that accounting has its own logic, that operations has its own rhythm, and that IT is always trying to hold the two together. The more I embraced that reality, the more valuable I became — not as a programmer, but as a problem solver.

NetSuite, for all of its quirks, is built for that kind of thinking. It gives you just enough structure to keep things stable, but enough flexibility to adapt. And when you combine that with a willingness to think creatively — to integrate, extend, and sometimes even work around it — you start to see what's possible.

Over time, I stopped chasing elegance and started chasing effectiveness. The goal wasn't to make NetSuite beautiful. The goal was to make it useful — to the people running the business, to the teams using it every day, and to the leaders making decisions based on the data flowing through it.

That's the real lesson that NetSuite — and enterprise software in general — teaches developers: the art of balancing technical ideals with operational reality. It's about being pragmatic enough to build what the business needs today, while still thinking ahead to what it might need tomorrow.

And when you get that balance right, you stop seeing systems like NetSuite as frustrating or limiting. You start seeing them for what they really are — powerful, adaptable platforms that can anchor an entire business, provided you're patient enough to learn them, persistent enough to work with them, and pragmatic enough to know when to bend the rules.

Common Complaints — and What I've Learned Along the Way

Over the years, I've had countless conversations with other NetSuite developers. And no matter where they come from, I hear the same complaints. Many of them are fair. But what I've learned is that almost every frustration in NetSuite hides an opportunity to better understand how the system really works.

"The APIs are inconsistent." They are. There's SuiteScript, SuiteTalk REST, SuiteTalk SOAP, and so on — each with its own quirks and capabilities. What works in one doesn't always translate cleanly to another. Early on, that drove me crazy. Over time, though, I realized that this diversity isn't arbitrary — it's historical. Each API reflects an era in NetSuite's evolution, and knowing which to use (and when) is part of becoming fluent in the platform. RESTlets remain my favorite because they bridge flexibility and control. Once you master them, you stop worrying about consistency and start focusing on results.

"The documentation is weak." It's getting better, but yes — NetSuite documentation often feels like it was written for people who already know the answers. I learned to rely less on official docs and more on experimentation, community forums, and my own internal documentation. Every time I figure something out, I write it down — and very often, I'll blog about it. My blog has become as much a personal development journal as it is a public resource. In fact, there have been times when I've been stuck on something, Googled it, and one of my own posts came up. It's funny how often I forget that I've already solved the same problem before.

"Debugging is painful." Absolutely. The built-in script debugger feels dated, and error messages can be cryptic. My workaround has been to instrument my code heavily — logging intelligently, capturing inputs and outputs, and testing iteratively. It's not glamorous, but it's reliable. Debugging in NetSuite teaches discipline; you learn to anticipate problems before they appear.

"SuiteScript doesn't feel like real JavaScript." That one always makes me smile — because it's true. SuiteScript is JavaScript, but it's a curated subset running inside a controlled environment. It's more like learning a dialect than a new language. Once I accepted that, I stopped expecting it to behave like Node.js and started treating it like what it is: a structured way to extend the ERP safely. That mindset shift changed everything.

"NetSuite is too expensive, and support is slow." For small or midsized businesses, the price can be eye-opening. And yes, getting quick answers from Oracle support can be frustrating. But "expensive" is relative — something I learned the hard way years ago while working in the FileMaker community. As FileMaker's costs increased, some of my smaller clients found it hard to justify. But others stayed with it because they recognized the value it delivered. I'm seeing the same thing with NetSuite. Yes, it's generally expensive, but it's also incredibly valuable. For many — if not most — businesses running on it, NetSuite is worth every penny they spend. My advice is simple: the best "support" comes from building in-house expertise. Invest in your own documentation, training, and tooling. The more self-sufficient you become, the more control you have — and the more value you can extract from the platform you're already paying for.

What I've learned through all of this is that NetSuite rewards curiosity and patience. The rough edges are real, but they're also where you learn the most. You don't conquer NetSuite — you collaborate with it. Once you accept that, the whole experience changes.

Finding My Place

Looking back, my journey with NetSuite has been less about mastering a platform and more about evolving as a developer. It's taught me to slow down, to look deeper, and to appreciate the layers of logic that sit beneath the surface of every enterprise system.

Patience taught me to understand before acting. Persistence taught me to keep going when the path wasn't clear. And pragmatism taught me to build for the world as it is — not the world I wish it were.

And when you find that balance — when you combine patience, persistence, and pragmatism — you also find a world of opportunity in the NetSuite space. While there are still moments of frustration, NetSuite can be a joy to work with. It's incredibly capable, adaptable, and yes — lucrative. There are so many fascinating businesses running on NetSuite, each with their own challenges, quirks, and opportunities to create something meaningful.

My own journey with NetSuite started in 2017, and I still genuinely enjoy the work I do. The nature of that work has evolved — especially with the growing excitement and potential around AI — but my core motivation hasn't changed. I still love building things that help businesses run better.

If I could go back in time, I wouldn't change a thing. NetSuite has tested me, taught me, and rewarded me in equal measure. It's been a challenging, fascinating, and fulfilling journey — and it's far from over.