You Hired a Developer. Now What?

Founder forums light up with the same question every week. The framing might change slightly, but the situation is always the same:

“I finally hired a developer. They seem great. We had a good first call. But now I have no idea if they’re actually making progress. How am I supposed to know if I’m getting ripped off when I can’t read the code?”

The comments underneath are full of non‑technical founders saying the same thing back in different words. They know some things, but not enough to be confident. They’ve already paid a few invoices and still can’t tell what’s real: they don’t have a link they’re proud to show a friend, they don’t have even one user flow that feels finished, and they don’t have a clear sense of what’s coming next.

By the time a founder’s asking those questions, they’re usually locked into a real commitment: a signed contract, a deposit already sent, a timeline promised to a cofounder, investor, or early user. Walking away isn’t a simple “no thanks” anymore. It means sunk money, awkward conversations, and starting from zero with someone new.

That’s what this guide is written for.

The Moment After You Sign

We have a lot of clients who started getting suspicious with their developers shortly after the contract was signed.

With the kickoff call done, a project board appears somewhere in the cloud, full of tasks with reassuring names like “Set up infrastructure” and “Finalize architecture.” But on the founder side, the questions start piling up.

• What should they actually click into? The GitHub repo? The Jira board? The Figma file?
• Is “in progress” on three backend tickets good or bad for week two?
• Is it normal that everything visible to them still looks like a wireframe?

A lot of content covers how to find developers or what to ask before hiring, but once the work begins, the guidance gets thin. Most advice boils down to “trust the process” without explaining what a healthy process looks like from a non‑technical founder’s perspective.

It’s possible to hire a capable developer and still end up with a bad build if there’s no way to make decisions together while the work’s in motion. In practice, that looks like:

• No shared definition of what has to be working in the next 4–8 weeks.
• No agreement on which tasks are “nice to have” versus “launch blockers”.
• No regular moment where the founder sees the product and decides what to cut or keep.

Technical fluency helps with all that, but the core needs are simpler. The team needs a way to define progress in terms of screens and flows, name risks in plain English, and adjust scope before the budget’s gone.

What Actually Goes Wrong

Many founders assume the catastrophic mistake is hiring the wrong person. That happens, but it’s less common than another scenario: thoughtful founders working with capable developers and still reaching the end of the budget without anything they’d feel comfortable putting in front of ten strangers.

Here’s how that usually plays out:

• Casual scope creep. Someone says a feature will “only take a few hours”, so three or four of those get added every week. Nobody’s tracking that those “few hours” add up to weeks.
• Sliding timelines with fixed scope. Launch dates move, but the list of features doesn’t shrink. Every delay keeps the full wishlist intact.
• Artifacts instead of app. Founders keep seeing pitch decks, new Figma screens, and updated diagrams, but there’s still no URL where a user can sign up, log in, and do something useful.
• Vague status reports. Weekly updates sound like “we’re finalizing the backend” or “we’re refactoring the architecture”, but if you ask “what can a user actually do today?”, the answer’s fuzzy.

The common thread in almost every situation like this is the absence of a shared agreement on two things:

1. What the near term is supposed to produce in terms of user actions (“a parent can do X, Y, Z”), and

2. What will be dropped or downgraded the moment the plan runs into time or budget limits?

Without those, every micro‑decision defaults to “sure, let’s add that”, and the build slowly drifts away from a shippable core.

Defining “Good” Before the Work Starts

The first question worth pushing on before more work happens isn’t whether the developer’s qualified. It’s:

What will a founder be able to do inside the product in six to eight weeks that they can’t do today?

This needs to translate into something you could show on a Zoom call or in a coffee shop: a specific screen flow, not a technical milestone.

Not:

• “The database schema will be finalized.”
• “The backend will be ready for scale.”

But:

• “A parent can sign up, log in, see a list of their children’s classes, and send a message to one teacher.”
• “A coach can create a program, invite five clients, and record one habit per client, once a day, without the developer touching the data.”

That question tends to fall on deaf ears because most early project conversations happen at two levels that don’t connect.

• Developers talk in tasks: set up authentication, implement Stripe, configure the pipeline.
• Founders talk in vision: “I want parents and teachers to connect,” “I want creators to manage all their clients in one place.”

The space between those two is where “six weeks” becomes “six months”.

Writing down a concrete, plain‑language end state forces everyone to commit to something you can literally click through together.

For example:

• A parent can create an account, log in, and send a message to one teacher.
• A coach can sign up, invite five clients, and record one habit per client.

You can test those flows yourself. You can put them in a Loom video. You can show them to a potential investor. That’s tangible.

Once that exists on paper and both sides have agreed to it, the conversation about what’s allowed to be rough or manual in the first version becomes much easier.

Very specific tradeoffs might be:

• The admin panel’s a basic table, not a polished dashboard.
• New users are approved manually by the founder once a day.
• Reports are exported as CSV instead of a custom analytics page.

Agreeing to that upfront protects the timeline from perfectionism that shows up as “let’s just make the admin nicer” while the core user journey still isn’t working.

A Weekly Rhythm That Actually Works

The natural next question is what a founder’s supposed to do every week while the build’s in motion. The instinct’s often to either disappear and check in once a month or to sit in on every standup, trying to follow implementation details.

Both patterns tend to make outcomes worse:

• If you disappear, you only see bad news when it’s too late to change anything.
• If you hover at the technical level, you slow the team down without actually improving decisions.

A consistent weekly call with a simple, unchanging agenda gives you a middle path.

1. Start with visible progress

The first element of that agenda is seeing progress you can literally use.

Instead of “How did the week go?”, you ask:

• “What can a user do this week that they couldn’t do last week?”
• “Can you show me, on screen, where that happens?”

You’re asking for something like:

• A sign‑up flow that now sends a real confirmation email.
• A settings page where changes actually save and show up later.
• A first pass of the messaging screen, even if the design is rough.

A screen share, a staging link, or a short recorded walkthrough is enough.

If several weeks go by and the answer is always a description instead of a demo (“we’re almost done refactoring X”, “we’re close to wiring up Y”), that pattern tells you the work isn’t converting into a visible product.

2. Name risk early

The second element’s a direct conversation about risk, in plain terms.

Questions such as:

• “If we keep going exactly like this, what’s the biggest risk to hitting our target launch date?”
• “What’s one assumption about users, data, or integrations that might be wrong?”

You’re looking for concrete examples, like:

• “The integration with SchoolX’s API is undocumented, so it might take longer than we think.”
• “If Stripe onboarding is delayed, payments may not work at launch.”

Hearing “no risks” for weeks in a row is almost unheard of. Every real project has at least one risk that is likely on your dev teams radar.

3. End with decisions

The third element’s clarity on what only the founder can decide before the next call.

Developers often stall because they’re waiting on things like:

• Which fields are required for onboarding?
• Which of the two design options should be used?
• Whether to prioritize speed or flexibility in a particular feature.

Ending every call with:

• “What do you need from me in the next seven days so you’re not blocked?”

gives you a short list you can actually complete. That list is your real job between meetings.

Reading the Signals Without Reading the Code

Even with a clear near‑term goal and a regular rhythm, there are moments when something feels off. You don’t need a technical explanation to take that feeling seriously.

The patterns worth paying attention to are things you can observe directly.

Some concrete signals:

• No new links. Weeks go by, and you’re still clicking the same staging URL with the same capabilities. Any “changes” are invisible unless the developer shares their screen.
• Explanations without options. Every request for a small change turns into a long explanation of why “it’s more complex than it sounds”, but you rarely hear, “here’s the quick version we could do instead.”
• Growing estimates, fixed features. The number of weeks and dollars keeps going up, but nobody suggests removing or shrinking any feature to compensate.
• Unclear recent progress. If someone asked you, “What shipped in the last two weeks?”, the honest answer would be “I’m not sure.”

When these patterns show up, the useful move is to change the shape of the conversation, not to pretend everything’s fine.

Very concrete questions you can use:

• “What’s the smallest version of this feature that still helps a user?”
• “If we drop this item to a later phase, how many days or weeks do we get back?”
• “If we had to show a working demo to ten users in four weeks, what would you remove to make that possible?”

Developers who engage with those questions directly usually come back with options: a trimmed‑down version, a simpler flow, a clear “this is possible, but we’d need to cut X”. Developers who only respond with “it’s not that simple” without alternatives are telling you that tradeoffs will always be hard to discuss.

What to Do When AI Enters the Conversation

Founders are increasingly told that AI tools will make their build faster and cheaper. Sometimes that’s accurate. It can also be a way to gloss over who’s doing the work and how maintainable the result will be.

Again, you don’t need to understand the internals of the tools. You do need clear, specific answers.

Practical questions:

• “Where in this project are AI tools being used, and what tasks are they handling?”
  • Example: “We use AI to generate boilerplate code for CRUD screens.”
  • Versus a vague: “We’re using AI everywhere to speed things up.”
• “Does any user data or proprietary information leave our environment and go to external systems?”
  • Example: “We only send synthetic test data to external tools, production data stays in our infrastructure.”
• “If another developer joins in a year, how will they know which parts of the code were generated or heavily assisted by AI?”
  • Example: “We annotate those sections and follow our standard code review process.”

These aren’t trick questions. They map directly to your future ability to:

• Keep user data safe.
• Hand the project to a new developer if you need to.
• Avoid a full rewrite just because nobody understands how the first version was glued together.

AI can genuinely accelerate good development, but it also makes it easier for low‑quality teams to stitch together something that looks like a product until you try to change it. Early, specific questions are how you tell which camp you’re in.

When You Realize the Build’s in Trouble

Some founders eventually reach a point where the gap between what they expected and what exists is no longer possible to ignore.

Concrete signs:

• The “MVP” still doesn’t let a user complete even one full journey without developer intervention.
• Every demo has a disclaimer: “This part’s hard‑coded for now,” “This button doesn’t do anything yet.”
• The development team’s updates are mostly about rework, refactoring, or “getting ready” for something that never quite appears.

The two most common reactions are:

• Keep paying in the hope that a fully‑formed product appears if you just “get through this phase”.
• Cut the project off abruptly, losing not only money but also the context and learning inside the current build.

A more effective approach starts by turning “this feels wrong” into a written, testable statement.

Very specifically:

• Write down 3–5 user flows that should work end-to-end within the next month.
• Describe what you’d need to see in a demo to honestly say “this is usable for a small group of real users.”
• Share that list and ask the team whether it’s realistic given the remaining budget and time.

Then request a checkpoint that matches that list.

Not a new statement of work, not a nicer Figma deck, but a URL or build where you can click through those flows, even if it’s visually rough.

Once that checkpoint exists, the options become clearer:

• Reset and narrow. Keep working with the same team, but lock in a smaller scope and pause everything else.
• Cut to a milestone. Deliver only the core flows, stop, and then decide whether to continue investing.
• Close and carry forward. End the engagement, pay for what truly exists, and take the flows, designs, and lessons to a new partner.

In each case, the aim is to protect the money and time you haven’t spent yet, rather than chasing what’s already gone.

The Advantage Non‑Technical Founders Actually Have

Non‑technical founders often carry a concern that their lack of technical depth is an unavoidable disadvantage in software projects. The founders who navigate development well tend to see the situation differently, because they focus on the parts of the process only they can own.

The decisions that determine whether an early product succeeds or fails are rarely about specific libraries or frameworks. They’re about:

• Which user journey will be fully supported first?
• Which “nice to have” items can wait until after ten real users are using the product?
• How often does the team look at the product together instead of just talking about it?

Those are decisions about clarity and focus rather than code.

The advantage non‑technical founders can bring is the willingness to:

• Ask direct questions when something’s unclear.
• Establish a simple rhythm of “show me, then let’s decide”.
• Stay anchored to real user flows when everyone else is tempted by extra features.

Practically, that looks like:

• Writing down, in plain language, what the product should enable in the next six to eight weeks.
• Asking to see that exact flow, click by click, in a weekly demo as soon as pieces exist.
• Noticing when status updates drift away from those flows and bringing the conversation back.
• Being prepared to say, “Let’s ship this smaller version first,” even when it means postponing things you personally like.

One concrete step for any founder already mid-build is to write a short description of what they expect to be able to do in the product six to eight weeks from now and share it with the development team.

If the reply is “Yes, that’s exactly what we’re building,” followed by a plan for how it’ll show up in demos, that’s a good sign. If the reply is a long technical explanation that never quite answers the question, that’s your signal that the build needs a different kind of leadership from you.