Partner with Everyone Who Builds at AppZoro

The question I get a lot is, ‘What happens after the first couple of months? Do we still get the same attention?’ And I get why people ask that, the first few weeks are easy - everyone is excited, everyone is available. The real test is month four or five. For me, consistency matters more than making everything sound perfect. If something is slipping, I’ll tell you, if we’ve made a mistake, I’ll tell you that too. I’d rather have one uncomfortable call early than spend the next three weeks pretending everything is on track.

I’ve definitely been part of projects where we built something, launched it, and then realised users just didn’t care about it as much as we did. That hurts a little, because you know how much work went into it. These days, when someone asks for a feature, my first reaction is usually, ‘What problem are we actually fixing here?’ Not because I want to kill ideas. I just don’t want the team spending eight or ten weeks building something that sounds good in a meeting but adds very little once it reaches the user.

I probably say ‘why?’ more than people would like. Someone will say, ‘We need this button here,’ and I’ll ask why. Then they explain it and I’ll probably ask why again. It can be annoying, I know. But usually there’s a reason behind the request that is more important than the request itself. I’d rather understand that before I start moving things around on a screen. A design can look clean and still be confusing. Users don’t care how nice our Figma file looked if they can’t figure out what to do next.

Founders usually come into roadmap discussions with a lot of ideas, which is actually a good problem to have. The difficult part is deciding which idea matters to the customer right now. I’ll often ask, ‘If we only launched three of these things, which three would actually help someone choose us or keep using the product?’ That question changes the conversation pretty quickly. I’m not interested in making the product look busy. I’m interested in making the value obvious.

Adding people to a project is easy. Adding the right people without slowing everything down is the hard part. I’ve seen teams double in size and somehow become less productive because everyone new is trying to understand decisions that were made months ago. We try to avoid that. When somebody joins a project here, they already know how we work, how reviews happen, what ‘done’ actually means. They still need context, obviously, but they’re not starting from zero. That makes a much bigger difference than people realise.

Clients sometimes expect the technical conversation to be about the newest framework or whatever everyone is talking about that month. Most of the time, I’m thinking about something much less exciting: who is going to maintain this later? I’ve inherited enough complicated code to know what that feels like. So if a simpler technology does the job well, I’m completely fine choosing the simpler option. Good engineering isn’t about showing how clever we are. It’s about making sure the product still makes sense when somebody else opens the code two or three years from now.

People assume my job on the first call is to convince them to work with us. I don’t really see it that way. I’m trying to figure out whether the project makes sense for both sides. Sometimes I’ll hear what someone needs and think, ‘You actually don’t need a full development team for this.’ And I’ll say that. I’d rather lose a deal because I was straightforward than win one by promising something we shouldn’t be promising. If we do end up working together, I want the relationship to start with that kind of honesty.

Most project problems don’t arrive looking like a crisis. They start with something boring. A status update gets missed. A responsibility becomes unclear. Someone assumes someone else is handling something. On its own, none of that looks serious. But if you ignore enough of those small things, suddenly the project feels messy and nobody can point to the exact moment it happened. A lot of my job is catching that stuff while it still looks boring.