Three years ago, we started taking freelance projects on Upwork. We were decent developers, optimistic about our skills, and completely unprepared for what founders actually need.
We've now delivered 50+ projects. Some raised funding. Some didn't. Some are still running. Some are dead. The difference wasn't usually the code—it was everything that happened before we wrote a single line.
This is what we learned.
The problem isn't what founders think it is
Most project briefs sound like this:
"I need a mobile app like Uber but for dog walkers. It should have real-time tracking, in-app payments, reviews, and push notifications. I have six weeks and $15,000."
The real conversation should start here:
"Have you talked to 20 dog owners who would pay for this? Do they actually want an app, or would a WhatsApp group work? What's broken about the current solution that people care enough to switch?"
We learned to ask these questions in the first call. Not to be difficult—to save everyone time and money. If a founder can't answer them clearly, the project will fail no matter how good the code is.
What we do now: We spend the first 30 minutes of every discovery call challenging the idea. If the founder gets defensive, we know they're not ready. If they light up with better questions, we know they've thought it through.
Scope creep is a communication problem, not a feature problem
Early on, we'd start a project with a clear feature list. Two weeks in, the client would say: "Can we add user profiles? It's just one more screen."
We'd say yes because we wanted to be helpful. Then another feature. Then another. The timeline doubled. The budget blew up. Everyone was frustrated.
The mistake wasn't saying yes to features—it was not explaining the cost of saying yes.
What we do now: Every new feature request gets a response in this format:
- What it costs (time/money)
- What it delays (other features)
- When it could happen instead (next sprint/phase 2)
Most features get deferred once founders see the tradeoff clearly. The ones that don't are actually important.
Most founders don't need custom software
We've turned down more projects than we've accepted in the last year.
Why? Because half of them could be solved with:
- Airtable + Zapier
- Webflow + Memberstack
- A spreadsheet and a VA
Custom software is expensive and slow. It only makes sense when:
- The problem is so specific that no tool fits
- The founder has validated the market and needs scale
- Differentiation depends on the product, not just the idea
We've had calls where we say: "You don't need us yet. Use [tool X] for six months, get 100 users, then come back when you need custom features."
Some founders get mad. The smart ones come back later and become great clients because they trust us.
What we learned: If you're selling honesty, you occasionally have to fire yourself.
The best clients have been in the problem for years
Our most successful projects came from founders who had:
- Worked in the industry for 5+ years
- Tried existing solutions and knew exactly what was broken
- Talked to 50+ potential customers before contacting us
These projects moved fast because decisions were clear. The founder knew what mattered and what didn't. We weren't building in the dark.
The worst projects came from:
- First-time founders with a "disruptive idea"
- No customer conversations
- A detailed feature spec but no understanding of the problem
These projects stalled because every decision required a debate. We'd ask "Why does this feature matter?" and get "Because users will love it" instead of "Because 12 people told me they'd pay for it."
What we look for now: Evidence of problem obsession, not solution obsession.
Technical debt is a business decision, not a failure
Founders hear "technical debt" and think we screwed up. That's not what it means.
Technical debt is when you intentionally build something quick and messy because speed matters more than perfection right now. It's a trade-off, not a mistake.
Example: One client needed an MVP in 4 weeks to pitch investors. We hardcoded some workflows that should have been dynamic. We told them upfront: "This will work for your pitch. If you get funded, we'll rebuild this part properly."
They got funded. We rebuilt it. Everyone was happy.
What changed: We started explaining technical debt in business terms. "We can launch in 4 weeks with some shortcuts, or 8 weeks without them. Here's what breaks if we take shortcuts, and when you'll need to fix it."
Once founders understand it's a choice, not a failure, the conversation gets easier.
Founder involvement is the single biggest predictor of success
Projects where the founder was in Slack daily, answering questions within hours, and testing features as we built them? Those shipped on time and succeeded.
Projects where the founder disappeared for days, delegated to a "project manager" who couldn't make decisions, or said "just build what you think is best"? Those dragged on, missed deadlines, and often died.
Building software is not like ordering furniture. You can't just spec it, pay for it, and come back when it's done. There are 100 small decisions every week that only the founder can make because they understand the business.
What we require now: At least 5 hours of founder time per week. If they can't commit that, we don't start.
Maintenance costs are invisible until they're not
We've had three clients come back after two years saying: "The app stopped working. Can you fix it?"
What happened?
- A third-party API changed
- A dependency had a security vulnerability
- The hosting provider deprecated a feature
The founders thought "finished" meant "done forever." It doesn't. Software rots. Platforms change. Security matters.
What we do now: Every proposal includes a maintenance section with realistic ongoing costs. Some founders choose to handle it themselves. Some don't. But nobody is surprised anymore.
Most projects fail from lack of clarity, not lack of skill
We're better developers now than we were three years ago. But that's not why our success rate improved.
What changed was learning to spot unclear projects early and either fix the clarity or walk away.
The pattern is always the same:
- Vague problem → vague requirements → vague product → failed launch
Clear problem → focused MVP → fast iteration → actual users.
The best clients answer these three questions in the first call:
- Who is this for, specifically?
- What exact problem does it solve for them?
- How will you reach them once it's built?
If they can't answer all three clearly, the project isn't ready.
What we'd tell ourselves three years ago
- Ask harder questions upfront. Saying yes to everyone is not being helpful. It's being lazy.
- Charge more. Cheap projects attract clients who don't value what you do. Expensive projects attract clients who care about outcomes.
- Fire bad clients fast. The warning signs are obvious. Ignoring them wastes months.
- Underpromise, overdeliver. Everyone wants aggressive timelines. Build in buffer. Ship early. Look like heroes.
- Documentation is not optional. Future you will hate past you if you skip it.
- Maintenance isn't extra work—it's part of the business. Price it in or regret it later.
- The best marketing is being honest. We get more work from telling people they don't need us yet than from overselling what we can do.
What's next
We're not trying to scale into a 50-person agency. We're trying to get better at picking the right projects and doing them well.
We're also turning down more work because we learned the hard way: taking every project means doing none of them well.
If you're thinking about working with us, here's what we care about:
- You've talked to real customers
- You can explain the problem clearly
- You're willing to be involved
- You're building something that actually matters to someone
If that sounds like you, let's talk.
If you're still figuring things out, that's fine too. We've been there. Come back when it's clear.
More from Zumetrix Labs: