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. In our experience the difference wasn't 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
Here is what a project brief can sound like:
"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 is at risk no matter how good the code is.
What we do now: We use the start of a discovery call to challenge 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)
Seeing the tradeoff clearly changes the conversation. Some features get deferred, and the ones that don't are the ones that matter.
Some founders don't need custom software
We've told founders they don't need us yet, and we mean it.
Why? Because some problems can 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.
We look for founders who have been in the problem
What we look for in a founder:
- Time spent close to the problem, in the industry
- Existing solutions tried, with a clear view of what is broken
- Conversations with many potential customers before contacting us
In our experience, decisions are clearer when the founder knows what matters and what doesn't. We aren't building in the dark.
The warning signs look different:
- A "disruptive idea" with no customer conversations
- A detailed feature spec but no understanding of the problem
Without that grounding, every decision can turn into 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: say a founder needs an MVP in 4 weeks to pitch investors. You hardcode some workflows that should have been dynamic, and you say so upfront: "This will work for your pitch. If you get funded, we'll rebuild this part properly."
Debt taken on knowingly is a business decision. Debt nobody mentioned is a surprise.
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 changes how a project runs
In our experience, a project moves differently when the founder is in Slack daily, answering questions within hours, and testing features as we build them.
When the founder disappears for days, delegates to a "project manager" who can't make decisions, or says "just build what you think is best", decisions stall and the project drifts.
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
Clients have come back after a couple of 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: Our proposals include a maintenance section with realistic ongoing costs. Some founders choose to handle it themselves. Some don't. But nobody is surprised anymore.
Clarity matters more than skill
We're better developers now than we were three years ago. But what changed our work most was learning to spot unclear projects early and either fix the clarity or walk away.
The pattern as we see it:
- Vague problem → vague requirements → vague product → failed launch
Clear problem → focused MVP → fast iteration → actual users.
Three questions we ask 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. In our experience, cheap projects attract clients who value the work less.
- Fire bad clients fast. The warning signs show up early. Ignoring them costs 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'd rather tell people they don't need us yet than oversell 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 choosier about the work we take, 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: