Hiring someone to build your software is one of the few things you buy where you pay first and only find out months later whether you got anything. So of course the first month makes people nervous. You’ve handed real money, and a half formed idea you actually care about, to a person you mostly know from a couple of calls, a decent looking website and perhaps a recommendation from someone you’re connected with on LinkedIn.
I want to walk you through what a good first 30 days looks like, from my side of the table. Partly so you know what to expect. Mostly so you can tell early, while walking away is still cheap, whether the person you hired was the right call.
You pay the deposit, and they go quiet. A week passes, then two. You send a friendly “how’s it going?”, get back “going great!” and not much else. Four weeks in, a big invoice lands next to a demo that looks nothing like what you wanted.
This is rarely bad luck. It’s mostly the absence of a process, and it’s avoidable.
You’d never hand a builder your keys, wire the deposit, and then not hear from them until the kitchen is “done.” You’d want a walkthrough first. A drawing you both signed off on. A rough schedule. A site you can actually visit on a Saturday to see the wall going up in the right place.
Software is the same, with one nasty difference: the building site is invisible. Someone has to deliberately give you a window into it. If your engineer doesn’t set that up for you in the first weeks, you’re renovating blind and just hoping it turns out as you expected.

Before a line of code gets written, the important work is pinning down what “done” means for the first iteration. Not for your whole idea, just the Minimum Viable Product (MVP).
That starts with your business, not the feature list. Who uses this, what breaks their day today, what “success” looks like in plain terms. A feature list tells me what you asked for. The business tells me what you actually need, and those two are not always the same thing.
This is also where, if I’m any good, I sometimes talk you out of things. That the login system you sketched can be a service you rent for a few euros a month instead of something we build and babysit forever. That half the features on the list belong in version two, or in the bin.
I usually run this first look for free, and I only put a price on it if the project turns out to be genuinely large, in which case I’ll say so plainly before anything goes on the clock. A first month that ends with a smaller, sharper plan than you walked in with is not wasted, rather, it’s protection against the unknown.
An engineer who never pushes back, never trims the list, and says “yes” to everything will pave the road to an expensive future.
Once we know what we’re building, the first few days are unremarkable, and that’s a good sign. Two things happen.
We get you set up as the owner of everything from the start. The code, the hosting, the domain, the accounts. In your name, not mine. Losing access to your own accounts is one of the most common ways a business gets stranded later, and it costs nothing to get right on day one.
And we agree how we’ll work. A standing time to check in, and one shared place where the work is visible to you without having to ask.
You should have both pretty soon into the engagement.
Within the first couple of weeks, working software should show up. Tiny is fine. A single page that does one real thing from start to finish beats a beautiful slide deck describing ten features that don’t exist. And then it should keep showing up, every week or two, a little more each time.
This is the most honest record of where a project really stands. A status update is easy to give and easy to fudge, and that’s exactly where trouble hides before it surfaces later. If you’re seeing the work regularly, you can steer it while it is still cheap to do so.
None of this works if it’s only me. Be reachable for decisions.
A project can stall for a week waiting on one answer only you can give, and that’s just lost time you can’t get back. Give feedback fast and blunt, “I hate this, it’s confusing” is far more useful to me than a polite silence.
And please resist the urge to add “one small thing” every few days. Each one sounds harmless on its own, but the steady stream of them is exactly what that initial scoping was meant to spare you.
By the end of this period you don’t need to know if the software is good yet. It’s too early for that. But you can already tell, with surprising accuracy, whether the collaboration is.
Signs it’s going well:
Signs to worry:
The first 30 days aren’t really about how much gets built. They’re the cheapest chance you’ll get to find out two things: whether you can see what’s happening, and whether you can change course without a fight.
And if the first month feels off, take it seriously. It’s tempting to shake it off. You already paid, you don’t want to start over, and you tell yourself it’ll get better once things start moving. In my experience it usually doesn’t, not on its own.
If you’re about to commission something and want to know what a good first month should feel like, or you’re a few weeks into one and something feels off, I’m happy to talk it through before it grows into a bigger problem.