You can’t build enterprise apps on feelings.

I originally built Turbobase to address the pain I experienced leading hundreds of enterprise NetSuite implementations. Working with our customers, I started to see how much more Turbobase could become.

And because of AI, I don’t have to raise millions of dollars or hire a massive development team to pursue that potential. I can put more than 20 years of experience, and the insights I earned along the way, to work building it now.

So, I did.

But the experience matters. The ability to produce more code doesn’t remove the need to understand what that code is going to do to a business.

The hard part is knowing what you’re changing

When you spend time inside a complicated NetSuite instance, you realize how much you need to understand before changing anything. What the records mean. Which scripts depend on them. Why someone built a workflow that way in the first place.

That last question can take longer to answer than writing the replacement.

A field that looks redundant might support a customer agreement. An awkward approval step might exist because somebody learned an expensive lesson. A script that nobody wants to touch might still be doing something essential every night.

You need to find out before you decide that a cleaner screen is an improvement.

That understanding is just as valuable when you’re building something new.

Take an app that gives a customer an order update. It sounds straightforward: find the order, check the status, show the answer.

Then the questions start. Does “available” mean sitting in a warehouse, or available after existing commitments? Has the whole order shipped, or just part of it? Is the delivery date confirmed, or is it an estimate somebody entered last week? Can this person see every order on the account?

Now let the user change something. Which system should receive the update? What needs approval? Will an existing workflow respond to it? What should happen if the update fails?

The screen might be simple. The job behind it still needs to be understood.

Without that understanding, you can end up adding complexity and dead weight. You’re making things worse, no matter how great you feel about your new app.

That’s where vibe coding breaks down in the enterprise.

You need guide coding, not vibe coding

You can’t build enterprise apps on feelings.

You need a body of knowledge about the business: its systems, its rules, its relationships and the decisions buried in years of customizations. You need structure that gives AI something useful to work from and boundaries to work within.

That’s what I mean by guide coding. Describe what you want to build, then guide it with what your business actually knows.

For that order-update app, the guidance needs to include which records to use, what their fields mean, how current the information needs to be and whose permissions apply. If the app can make changes, it also needs clear rules about what it can change and how those changes will be checked.

Some of that knowledge lives in the system. Some lives in documentation. Some still lives with the person who gets called when something breaks.

It needs to be brought together, checked and kept useful as the business changes. Otherwise, the next app inherits the same guessing game.

This also means being honest about what you don’t know. If nobody can explain why an approval exists, that is a question to resolve with the business. Giving AI permission to work around it doesn’t resolve it.

Experience helps you ask those questions. A shared body of knowledge means the answers can help the next person building something, too.

The work doesn’t stop at one platform

The more time I spent working through this with customers, the more obvious the broader opportunity became.

Someone in operations needs to investigate a stock issue. A team needs the customer record, the last conversation and the next piece of work in front of them. The information exists, but the person doing the job has to gather it from several places before they can act.

That is useful territory for a business app. It starts with an actual job that needs doing, and the knowledge required to do it properly.

We’ve been putting this into practice with our own operations app on Turbobase, bringing customer information, conversations and work together from several systems. Using it to run our own business gives us a daily opportunity to see what works and what needs work.

It also keeps the questions practical. Can we find the right customer information? Can we understand the conversation that led to a piece of work? Can someone pick that work up without asking everyone else to reconstruct the history?

NetSuite is where this started, and it remains a big part of what we’re doing. But the work inside a business rarely stays inside one platform. The apps we build need to reflect that.

Where I’m taking Turbobase

I’m building Turbobase toward infrastructure for apps that understand the business behind them. The knowledge we gather to make sense of an existing system becomes a foundation for building what that business needs next.

AI gives me the ability to act on ideas that once would have needed a much larger team and budget. My experience gives me a place to start, and our customers keep showing us where the useful work is.

Over the next few weeks, I’ll share what we’ve built, how we’re using it and what we’re learning along the way. I want to show the app, and the thinking that makes it useful.

Because getting something onto a screen is only the beginning. Somebody has to use it to get their work done.