It started with my own chaos.
I'm a full-stack software engineer by training. I just finished my degree. I started building systems in 2023 the way most people do: I needed to organize my own work, and the tools I tried were all half-answers. So I built the thing properly. Then I did it again, for someone else.
The engineering background made the rest straightforward. Databases, relations, logic, integrations: none of it was mysterious. So when friends, then their friends, then their companies started asking me to build things for them, I already had the muscle. The first 100 builds weren't a strategy. They were just me saying yes.
Learning the software is easy. Designing the system isn't.
Every company I meet has already bought the tools. A CRM, a project tool, a shared drive, an automation someone set up and left. The software was never the missing piece. The design was. Nobody sat down and worked out how the company should actually run before switching things on.
That's the hard part, and it's the part I'm good at: translating how a business really operates into workflows, integrations, automations, and habits that hold up under real use, on a Tuesday, with a deadline. Most templates skip it. Most consultants stop right before it.
Different industries. The same shape of problem.
Architecture firms, engineering consultancies, creative agencies, production companies, consulting firms, event and interior design businesses: I've built systems across most kinds of project-based service companies. The industries look nothing alike. The problem underneath is almost always identical: the company grew, the operations never got designed, and now sales, projects, and delivery run on spreadsheets, chat threads, and whatever a few key people remember.
That's what Stackwork solves. Not a specific industry. A specific stage. The point where a company is big enough that improvising the operations has started to cost real money, and nobody inside has the time or the distance to fix it.
Diagnose first. Then build for how you actually operate.
Every engagement starts with a diagnosis: interviews with you, and the people who actually run the work. Not to pitch. To map. How work comes in, where it stalls, who does what, what gets dropped, and where you're still doing things nobody else can see. Only then does anything get designed, and only then do we decide which software it belongs in.
I never take on more implementations than I can stay close to. That's how the work stays custom instead of templated. And I stay involved after launch, because the only way you find out what a system is missing is by running the real business on it.