Lessons from Shipping 50+ Products as a Dev Agency

We've been doing this for 6 years

Devnull Digital has shipped over 50 products since I started the company in 2019. SaaS platforms, mobile apps, e-commerce sites, internal tools, IoT dashboards, delivery systems — a pretty wide range of stuff. Some went on to raise funding and scale. Some didn't survive contact with the market. All of them taught us something.

Here's the honest version of what we've learned.

The scope is never what you think it is

Every single project has had scope surprises. Every one. No matter how thorough the scoping phase, no matter how detailed the requirements, there's always something nobody thought of until we're in the middle of building it.

The fix isn't better scoping (though that helps). The fix is building in buffer — time and budget — for the unknowns. We now add 15–20% to every estimate, and we're transparent with clients about why. "This is our best estimate based on what we know today. Here's a buffer for what we don't know yet."

Clients appreciate the honesty way more than a tight number that turns out to be wrong.

Communication problems are the #1 project killer

More projects fail because of bad communication than bad code. When expectations aren't aligned, when stakeholders aren't in the loop, when feedback cycles drag on — that's when things go sideways.

The specific things that have made the biggest difference for us:

Weekly demo calls. Not status updates — actual demos where we show working software. This catches misunderstandings early and keeps everyone aligned on what's actually being built.

A single point of contact on the client side. When decisions need approval from 4 people who disagree with each other, nothing moves. We ask clients to designate one decision-maker for the project.

Written requirements. Not because we're bureaucratic, but because "we talked about it on a call" leads to different memories of what was agreed. If it's not written down, it doesn't exist.

Say no to projects you shouldn't take

This took us a few years to learn. Early on, we said yes to everything. We needed the revenue and we wanted the experience. But some projects we should have walked away from.

The patterns we now screen for:

**"Can you just build this Figma file?"** If a client has designed a product in Figma without any technical input, the designs almost always have impossible or impractical flows. We need to be involved in the architecture, not just the implementation.

**Decision-by-committee.** If the first call involves 6 people with different visions, the project will stall. We need a clear owner.

**Unrealistic budgets.** If someone wants a Shopify competitor for $10k, we're not the right fit. We'd rather refer them somewhere honest than take the money and deliver something disappointing.

**No clear vision.** "Build me an app" isn't a brief. We need at least a basic understanding of the problem being solved and who it's being solved for.

Tech debt is a negotiation, not an accident

Every project involves tradeoffs between doing things "right" and doing things "fast." That's not a failure of engineering — it's a reality of building products with real constraints.

What matters is making those tradeoffs intentionally. When we take a shortcut, we document it. We tell the client: "Here's what we're doing, here's what the ideal version would look like, and here's when we should come back and clean it up." This way, nobody's surprised when we need a refactoring sprint later.

The projects that accumulate crippling tech debt are the ones where shortcuts are taken silently and never revisited. We've taken over codebases like this from other agencies and it's always painful.

The best projects have engaged clients

Our best outcomes are with clients who are actively involved — giving feedback quickly, testing builds, making decisions, and pushing back when something doesn't feel right.

The worst outcomes are when a client disappears for three weeks and then comes back with a list of problems. By that point we've built three sprints of features on top of assumptions that might be wrong.

We tell every client upfront: this is a collaboration. We need a few hours of your time each week. If you can't commit to that, the project will suffer.

Boring tech outperforms exciting tech

We've experimented with a lot of technologies over the years. And what we've settled on is mostly the boring, battle-tested stuff. Next.js, React, Node.js, PostgreSQL, Vercel, AWS. Not because we're not interested in new things, but because our clients need reliability.

When we introduce a new technology into a client project, we're taking on risk. If something breaks in a framework we've used for 50 projects, we can debug it in our sleep. If something breaks in a framework we've used for 2 projects, we're reading docs at 11pm.

We save the experimentation for our own internal products where we control the consequences.

Launch is the starting line, not the finish line

The most underestimated phase of any product is what comes after launch. Real users find real bugs. Real usage patterns reveal real performance bottlenecks. Real feedback highlights features you missed and features nobody uses.

We now build every project with a post-launch support phase baked in. The first 2–4 weeks after launch are critical — that's when you learn the most about whether the thing you built actually works in the wild.

Clients who budget for this phase do dramatically better than clients who treat launch as "done."

Every failure has made us better

We've had projects that didn't go well. Features that shipped late. Estimates that were way off. Technical decisions that seemed right at the time and turned out to be wrong. We've learned from every single one.

The company we are today is built on the mistakes we made in year one and two. And honestly, we're still learning. That's the nature of building custom software — every project is different, every client has unique constraints, and the technology landscape keeps moving.

What we've gotten better at is recognizing patterns early, communicating honestly about risks, and building relationships with clients that can survive the inevitable bumps along the way. That matters more than any technical skill.