The Invoice Arrived Before the Feature Did

The New Dev Opened the Files and Found Nothing

I was on a call recently, working through a SaaS build with my team. We had brought in a new developer - let's call him Rohit - to audit and continue the work a previous developer, Krishna, had supposedly completed. Krishna had submitted an invoice. The work was listed. The features were described. It looked like a legitimate bill for legitimate output.

Rohit opened the codebase.

No streaming. No implementation. Just a paste job of someone else's code that hadn't been tested, hadn't been integrated, and in some cases didn't connect to the actual platform inputs at all. The invoice had arrived. The features had not.

No drama. No confrontation. Just a new set of eyes and a flat statement: there is no code for this.

That moment is the entire lesson. And if you've ever paid a developer invoice based on their word alone, this post is written for you.

Self-Reporting Is Not Deliverable Verification

Here's what happens in most founder-developer relationships, especially early-stage SaaS builds: the developer tells you what they did. You read the message. It sounds plausible. You've been heads-down on other things. The deadline passed and you're relieved it's "done." You pay the invoice.

You have just paid for a description of work, not the work itself.

This is not a rare situation. It's the default situation when there's no verification system in place. And the reason most founders don't have a verification system is simple: they trust the person they hired, they don't have the technical background to audit the code themselves, and they don't want to slow things down by adding process.

I get it. I've spent over $300,000 on software projects that went nowhere. Some of that money was lost to bad decisions. Some of it was lost to exactly this - paying for work that sounded complete but wasn't. You learn eventually, but the tuition is expensive.

The fix is not complicated. It's just a rule: no invoice gets paid until someone other than the person who wrote the code confirms it runs.

That's it. That one rule would have saved me a significant chunk of that $300K.

What "Done" Actually Means

On the call, we were working through a backlog of four tasks for the SaaS platform. Streaming responses. Data validation improvements. Scraper improvements. And a more complex UI feature involving chatbot training and common question generation inside the Galadon platform.

Rohit had come in and the first thing he did was check whether the streaming code existed. It didn't. Krishna had claimed it was implemented. The invoice reflected it as completed work. But when Rohit checked, there was nothing there.

That's not a misunderstanding. That's a claim that doesn't match reality. And the reason we caught it was because a second person - someone with no incentive to cover for the first - looked at the actual files.

So when I talk about "done," I mean:

• The code exists in the repository. Not described in a message. Not promised. Actually there.
• It runs on the live environment. Not locally. Not in theory. On the actual server where users interact with it.
• A second person tested it. Not the person who built it. Someone else. Even if that's just you, the founder, clicking through the feature yourself.
• Edge cases were caught before you were told it's ready. If Rohit finds a bug, that's fine - bugs happen. What's not fine is Rohit finding that the feature was never built at all.

That's the difference between a feature being done and a feature being described as done. One of those is worth paying for. The other is a donation.

The Invoice Timing Problem

On the call, there was a moment where the question came up: do we pay the invoice now and then scope the next tasks? My answer was no. We pay when things are verified. Not before.

I said it plainly on the call: we pay the invoice when I see everything's ready.

That sounds obvious. But watch how many founders invert this. They pay on submission, not on verification. They pay because the developer needs the money to keep going. They pay because they don't want friction in the relationship. They pay because the developer seems trustworthy and the invoice looks right.

None of those are reasons to pay an invoice. The only reason to pay an invoice for development work is that the work exists and runs. Full stop.

And the way I've restructured our payment model going forward is task-by-task verification. Each bug fix, each feature - you get paid as soon as it's confirmed working. Not when you say it's working. When it's confirmed. If it takes a day, you get paid in a day. If it takes a week, you get paid in a week. That's a fast, clean feedback loop that rewards actual output.

This also means you have to scope things properly before you start. I told the team: give me maximum timelines and pricing for each task. Don't tell me one day if you know it'll take four. Give me the real number, commit to finishing by that date, and then get paid when it's done and verified. That's how you run a dev relationship like a business, not like a favor economy.

The Test Before You Ship Rule

There's a related problem that shows up in almost every early SaaS build: the developer pushes something and immediately says "test it on your end." Then you spend time clicking around, find something broken, report it back, and the cycle repeats. Two days go by. Nothing is actually moving forward. It's just expensive back-and-forth.

My rule on the call was simple: don't tell me to test it. Test it yourself first. Pretend you own the product and you have to push it out to customers. Ask yourself: is this good enough to show a client? Would you buy it if you were the customer? Only send it when you can answer yes to both of those questions.

If you're a founder and you're the one always catching bugs that should have been caught before they reached you - that's a workflow problem. Your developer's QA process is your inbox, and that's backwards. Fix it before it costs you another week of wasted discovery calls.

How to Structure the Next Dev Hire to Avoid This

I've talked before about how I've lost money to bad development decisions - not just the $300K in bad projects, but also situations where I had too many developers with equity stakes eating into the actual value of the business. The last SaaS I sold had six partners, mostly because I needed coders and didn't have another way to structure it. At the end of the acquisition, the equity split meant I walked away with far less than the outcome deserved.

The point isn't to avoid developers. It's to structure the relationship so that output is verifiable and payment is tied to confirmed delivery. Here's what that looks like in practice:

• Scope every task individually. Don't pay a monthly retainer for a vague scope. Break it into discrete, testable units of work. "Implement streaming responses in the chat interface" is a task. "Work on the product" is not.
• Require written estimates with maximum timelines. Not best case. Maximum. If it takes longer than the maximum, that's on the developer, not you.
• Use a second set of eyes before payment. Doesn't have to be a full audit. Just someone else checking that the feature exists and runs. A co-founder, a contractor, even yourself - as long as it's not the person who built it doing the verification.
• Pay task by task, not on a schedule. Invoice on delivery, confirmed by verification. This aligns incentives correctly. The developer gets paid faster for finishing faster. You don't pay for work that doesn't exist.
• Keep a written backlog and cross-reference it. When a new developer comes in, hand them the list of what was supposed to be built and ask them to confirm what's actually in the code. That cross-reference is your audit. It takes an hour and it tells you immediately whether the previous work was real.

The Bigger Pattern: Paying for Descriptions Instead of Deliverables

This problem isn't just about developers. It shows up everywhere in how early-stage founders spend money. Agencies that report "work completed" in a weekly email without showing the actual output. VAs who say leads were qualified without evidence. Consultants who describe what they did in a retro without linking it to a result.

The common thread is the same: you're paying for a description of work, not the work itself.

I've said this in other contexts too - I had a founder come to me excited about having eight Filipino virtual assistants qualifying 130 leads a week. He was excited. I asked him to do the math. Eight people doing 130 calls at fifteen minutes each. That's 32.5 hours of work per week. Spread across eight full-time employees. He'd built an infrastructure to avoid doing something he could have done himself - and he was paying full salaries for the privilege of the illusion of scale.

The description of scale isn't scale. A team doesn't mean output. An invoice doesn't mean delivery. You only know you got what you paid for when you can see the thing running, count the results, or have someone independent verify the work exists.

That standard applies to developers, VAs, agencies, and frankly anyone you write a check to.

What We Did Instead

On the call, here's how we moved forward once we confirmed what was and wasn't in the codebase:

We voided the assumption that any of Krishna's invoiced work was real until Rohit confirmed it independently. We didn't dispute anything publicly. We just drew a line: everything gets re-verified before we pay for it as existing work. If it's not in the code, it didn't happen.

We also reprioritized the backlog based on what actually existed and what Rohit could build without requiring skills he didn't have yet. Streaming first - because it's the fastest win and it makes the product feel significantly faster to users even if the underlying response time hasn't changed. Data validation next. Scraper improvements after that. And the Bubble-dependent UI features last, so Rohit could build confidence in that environment before tackling the more complex front-end work.

Smart sequencing. Verified output. Payment on confirmation. That's the whole system.

It's not complicated. It just requires you to stop treating invoices as proof and start treating verification as the only proof that matters.

One More Thing Before You Write the Check

If you're building a SaaS right now and you've got a developer relationship that's running on self-reporting and scheduled invoices, do this today: ask your developer to walk you through the last feature they said was complete. Screen share. Live. Not a video they recorded. Watch them open the environment, use the feature, and show you the code that powers it.

If they can do that in ten minutes, you're in a good place.

If there's suddenly a scheduling conflict, or the demo environment is "down," or the feature needs "a few more tweaks" before it's ready to show - you have your answer. You already paid for something that doesn't exist yet. The question now is how you restructure the relationship before you pay for the next one.

And if you're earlier in the process - still figuring out how to build, how to hire, how to structure your first SaaS without giving away all your equity or burning six figures on developers who copy-paste and disappear - that's exactly what we go deep on in Galadon Gold. Real calls, real code reviews, real accountability. Not theory.

The invoice should be the last thing that moves. Not the first.