From ERP Consultant to Indie Tool Builder

For more than a year, much of my work lived inside an ERP. First as an intern, then as a junior software engineer in previous work, I spent my days in its modules: purchasing, accounting, point of sale, and the customization tools that let you shape them to fit a business.

On my own time, I build small tools. The one I think about most is Snaply, a Windows tray app that keeps recent screenshots and files one drag away.

On paper, these two kinds of work have nothing in common. One is enterprise software that runs a company's operations. The other is a little app that sits next to the clock. But doing both taught me something I didn't expect: they ask the same question, "what should this software do?", and they answer it in opposite directions.

In ERP, nothing stands alone

When you implement an ERP, you learn quickly that no record lives by itself.

Take a Purchase Order. From the outside it looks like one document: a vendor, some products, quantities, and prices. Inside an ERP, it's the start of a chain. The order becomes a receipt when the goods arrive. The receipt updates inventory. The vendor sends a bill, and that bill turns into journal entries in accounting, with taxes, payment terms, and the right accounts attached. Change one step, and every step after it feels it.

That changes how you scope. A request like "can we add an approval step to purchases?" is never just about purchases. You have to ask who touches the record next, what they expect to see, and what breaks if the numbers don't line up at the end of the month.

So in ERP work, scoping means looking outward. You follow the process from start to finish before you change anything. You learn the standard flow first, because the modules already solve most problems, and custom changes should fill real gaps instead of re-creating what already exists. And you respect versions, because the same module can behave differently from one release of the platform to the next. I saw that firsthand while working through certification preparation across different versions.

The scope isn't really yours to decide. It belongs to how the business actually runs. Your job is to understand that well enough that the software fits it.

In an indie tool, everything is optional

Snaply is built around a small, everyday problem: finding the screenshot or file you just saved so you can drag it into a chat, an email, or a folder.

Nobody hands you requirements for something like that. There's no client, no approval chain, no month-end close. That sounds freeing, but it makes scoping harder, because when nothing is required, everything feels possible. Cloud sync. Accounts. Share links. Tags and search. Every one of those ideas sounds useful.

So in indie work, scoping means looking inward. Instead of following a process out to its edges, you keep cutting until the core job is obvious.

What each one taught me about scope

ERP work taught me to ask, "What does this touch?" A change is only as small as everything it's connected to, and the only way to know is to trace it.

Snaply taught me to ask, "What can I leave out?" A tool is only as clear as the one job it does, and every extra feature makes that job harder to see.

The two questions work best together. When I build my own tools, it helps to think like an implementer: before adding anything, trace where the data goes and what depends on it. And when I look at business software, it helps to think like a tool builder: the best configuration is often the one that leaves the most things alone.

I used to think enterprise work and indie work were separate paths. Now I see them as two sides of the same skill. One teaches you to respect the whole system. The other teaches you to protect the one thing that matters.

Good scope isn't about how much software you build. It's about knowing where it should stop.