The call that made me say no
A head of operations called me last year. "How many developers can you put on this for six months?" I said: "We don't sell developer-months. We deliver products that work." Silence. He almost hung up.
Six weeks later, he signed. Not because we'd convinced him. Because he'd tried two other vendors in between, and both had quoted by the day without questioning his scope. He'd seen the difference firsthand.
That's the difference I want to explain here. Because once you've seen it, you never confuse the two again.
The two models
There are two ways to deliver a product. They look the same from the outside. They're opposite from the inside.
The first one is usually called an agency, a dev shop, or a vendor. The contract is about time. You give a spec, they price in person-days. If the spec is bad, they ship a bad product, and technically that's not their problem.
The second is called a product partner. The contract is about an outcome. We challenge your spec because that's our job. If the scope is leading you off a cliff, we tell you before we sign, not after we deliver.
Hourly cost can be identical. The result over six months never is.
What a product partner does that an agency doesn't
Four concrete things:
- We say no. A product partner regularly refuses requested features. Not out of stubbornness. Because we've watched twenty other products live with that feature and we've seen what it does. An agency says yes, it's billable.
- We look at the numbers. We want access to your analytics, your conversion rates, your user feedback. Not to make pretty dashboards, to decide what to build next. An agency doesn't ask for access, it isn't in scope.
- We stay after launch. Launch isn't the end. It's the moment we find out whether we were right. An agency ships, invoices, leaves. A partner stays for the iterations that turn a mediocre product into one people actually use.
- We share standards. Code conventions, review process, observability, security. When we leave a project, your team can keep going without us because we've passed those standards on. The opposite of a lock-in model.
When we say no
A SaaS founder asked us last year to add an in-app chat module. "All our competitors have it." We looked at his adoption on a feature he was already underusing: 12%. We told him: before we add a new feature, let's double adoption of the one you already have.
He didn't love the answer. He expected a quote. Three months later, adoption was at 38% after two focused weeks on onboarding. The chat module never shipped. He doesn't need it anymore.
That's what saying no at the right time looks like.
Surgery or rewrite
When we inherit an existing product, the junior reflex is to rewrite everything. It's more exciting, technically cleaner, and almost always the wrong call.
A product in production, even badly coded, contains something no new code has: knowledge of real cases your users hit. Every weird line is often a patch for a case you forgot.
Our default approach is surgery: identify the three or four points that actually hurt (performance, critical tech debt, modules blocking evolution) and fix them without touching the rest. Six weeks instead of six months. Risk divided by ten.
An agency delivers what you asked for. A partner helps you ask for the right thing.
How we share ownership
Shared ownership isn't a buzzword. It's an operating practice. On every project, concretely:
- You have access to the code from line one. Not at delivery, from the first commit.
- Your decision-makers attend the end-of-sprint retro. Not to approve, to see what we're learning.
- Major technical trade-offs are written down and shared. Not in a deck. In the repo, next to the code.
- When we leave the project, we leave behind an internal team or a new partner capable of continuing. That's testable.
The simple test
If you want to know whether your vendor is an agency or a product partner, ask one question:
On Monday morning, who at your shop is thinking about my business?
An agency will give you the name of a project manager thinking about your timeline. A product partner will give you the name of the person who reviewed your latest numbers and has an idea to bring you.
Both have a place. They don't cost the same. They don't deliver the same.
If you're not sure
The right way to know who you're working with is to put them through the test on a small scope before signing the big contract. A thirty-minute product review is enough to see how we reason, what we challenge, and whether we'll say no when we should.