It’s been about 5 years since I launched that video about what I had learned from my first startup and losing $50k on the wrong developers. Of all the branding we’ve put out over the years, that poorly-filmed, poorly-spoken, and poorly-edited video still works to this day. Obviously, people are still getting burned, or very much afraid of getting burned. And today, I’m hoping to make the original message a bit stronger & a bit more informed.
Over the last 5 years, I’ve learned a lot. On paper, we’ve built up a strong track record of products, but the truth is for every client that ends up in a multi-year growth partnership with us, there’s at least another that won’t last a year. For every haymaker success story, we’ve had the polar opposite.
Seeing our fair share of success stories (Over $200 million raised, millions of users served, helping many of our clients retire if they wanted to), next to still too many stoppages of work (no funding, no traction, team issues), makes for an amazing sandbox to learn from and reflect on how we can create vastly more success than failures over time.
While we can’t change the reality that 90% of startups do fail (80% if you’re in Ycombinator), I can say with certainty that there is plenty that we do have control over, and that’s what I’ll focus on.
In no particular order, here is my updated list of truths about app development:
- It is important to get many things right on the first build.
- You need more than design and coders, and proactivity is as important as talent.
- When you’re building something truly new, developers will need rope to learn on the job.
- Understand this concept: disparate pay for disparate results.
- The best long-term hires are adaptable.
- The dirty secret: QA can easily become your biggest cost.
- Lastly, look in the mirror — that’s who this all hinges on.
Let’s dig in.
1. It is important to get many things right on the first build.
While not true a decade ago, MVPs now are no longer stick figure scaffolds like a twitter feed that can get throw together in a few days. Pretty much every app idea now is more sophisticated, not for the sake of sophistication but because the ecosystem is just much more mature. Even with web3, this is true => the speed of new product launches is just so fast and competitive, that not having a slick-feeling product with well thought-out UI/UX isn’t going to cut it anymore for a new dex or wallet.
So, the cost of scrapping the code starting again becomes untenable for most. We have to operate under the assumption that while we can change things up, we shouldn’t tear this down.
- If you don’t validate your design, you’re basically gambling when you start coding the thing, not having any data to back up that people want it.
- And once you start coding, if you go with the “ship fast and break things” mentality without proper devops / architecting / clean code from the beginning, the costs will rear their heads in the form of technical debt soon after.
Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. — https://www.productplan.com/glossary/technical-debt
To see our weapons of choice to de-risk the first build, see:
A good analogy for “getting things right the first time” is building a house. A new home is expected to last for half a century or more, so you don’t take shortcuts even if you use off-the-shelf products. Use a solid blueprint, structural soundness, a modern look and feel, and good flow / fengshui => it’s built to last and sells in any market.
2. You need more than design and developers, and proactivity is as important as talent.
If you have a disruptive idea and think you just need a UI/UX design and developers, you’re plainly mistaken. Product owner, project manager (whether a separate person or someone within the dev team), QA automation, devops engineer, marketing, bizdev => all non-optional to prevent ill-fated apps.
Ideally of course, you wear some of these hats yourself, not just to stretch the runway, but I strongly believe that hiring anyone (us included) is only going to ROI positively if you provide leadership and skin in the game. There’s simply too much to do and too much at stake, to hire out the entire process.
Here’s the way I visualize all these key roles:
- Product Manager: North star, grooms features to pave straightest road there, analytics master (esp. retention).
- Project manager: Planner, shepherd, transparency-maker.
- UI/UX: Delights the users.
- Dev: Writes clean code.
- Devops: Saves developers time by automating all repetitive dev activities, making the app hum and scale with infrastructure.
- QA automation: Saves developers time by writing automated tests (without this, be ready to see 1/3 to half the dev budget go to bug fixing)
- Marketing: Finds users at lowest cost of acquisition, so you know what it costs to get your next 10k users. (Then finds them again when channels inevitably diminish returns).
- BizDev: Sales, LTV expansion, partnerships (that lead to sales)
There’s a reason most seed rounds are $1–4million, 4x what they were 10 years ago. Just to make it for the next 2 years with quality hires at each of these positions, that’s a 7-figure payroll.
Second, if you hire great talent, but everyone just listens to you and executes on command, you’re better off not doing this at all. There is nothing that guarantees mediocrity like hiring a team of passive people.
For the first 2 years, your team better be thinking out of the box at every step, whether it be questioning product-market fit, a better way to code, or a cheaper way of acquiring users. That’s how you get the most out of the team, and getting the most out of the team is the only way to survive the game.
Spoiler alert: you don’t necessarily have to pay a 7-figure payroll to find this. We’re a swiss army knife for less than half the cost. Learn more here.
3. When you’re building something truly new, developers will need rope to learn on the job.
A reality reinforced by 7 years in the industry with a team that’s written 200k hours of code, looking at our most successful projects versus our least successful, and seeing how other high-performing teams operate.
Using the home analogy again, home building has predictable costs. You use the same materials, costs, concepts, with small deviations. Now imagine you’re not only building a custom home but you were asked to build a bat cave before Bruce Wayne did. Would you expect a bid to work out?
“So I should just give developers a blank check?”
No. The truth is complicated and somewhere in between. This is what I do:
- First, find technical leadership. Without this barometer, you’re just flying blind if you’re not a senior developer yourself.
- Together with technical leadership, set cost-controlled trials where you can vet developer production within a short time frame. Milestone passed, build trust.
- Put the developer on a larger scope (say a 3-month proof of concept) with weekly code reviews. The technical leadership will be the arbiter of whether the overages over estimates are justified. Milestone passed, build more trust.
- And just like any hire, as more milestones are hit, the more trust is gained, until one day, the developer you’re evaluating becomes one that now helps evaluate new developers. #thecircleoflife
The key point here is that, if you hold talented developers to a fixed price, you’re never going to attract the most talented developers in the first place or keep them for long. Do careful vetting upfront, but aggressively build trust, then switch to full-time employee treatment while continuing to vet work periodically.
TLDR: create an environment that balances your needs as a business founder with conditions that make it easy for the developer to go to bat for you. That’s where the ROI is made.
4. Understand this concept: disparate pay for disparate results
Last year, software developer salaries skyrocketed, especially in web3. This combines 2 concepts:
- You get what you pay for
- Ye’ old supply and demand economics.
There’s no industry where the idea of disparate pay for disparate results is more prevalent than in software. Going back to the idea of 10x engineers, or 10x teams, the right hire will give you outsized results, and you’re not the only person that will know this. With the mobility on today’s market, talented individuals will have other options if you act like you don’t know this! This level of transitory loyalty of course saddens me, but I’m just sharing the reality that we both face.
Let me give you a very transparent example:
On my own team, I don’t set everyone’s pay on the same scale. That’s because there are individuals on the team that contribute several X their value to growth, and those people need to be compensated differently than others that don’t. This is not a common belief among peers, but I believe it in my bones.
If you go to Glassdoor and offer a median salary per position, you’ll get what you pay for: median talent.
Form a thesis for what certain key roles will add outsized impact to your bottom line, and invest liberally into those. To make the numbers work earlier on, I believe it’s ok to hire fractional roles to make the numbers work earlier on, as long as it’s a steady role.
5. The best long-term hires are adaptable.
Raise your hand if you‘ve ever posted a JD that looks like this:
5 years of experience with React Native , 4 years of experience with NodeJS and MongoDB , 3 years of experience with GraphQL, AWS, Firebase….
Oh, the specificity of it all!
What I’ve learned the most is that there’s a difference between an immediate need and a long-term need.
If you have an iOS project that needs Swift expertise right now, of course you shouldn’t be taking a flier on someone coming from a totally different language. But long term?
One of our lead Swift developers spent 2 months picking up React and React Native, and now he’s a lead developer in both stacks.
One of our lead React developers spent a similar amount of time picking up flutter, and recently served as the lead flutter developer for a fortune 1000 company.
Our now lead ML developer didn’t have that much ML experience and when we hired him, he had as much experience as an Epic analyst as ML. In most projects we brought him onto, the desired technology was something he’d read about rather than experienced with. But what he lacked in experience, he made up with relentless curiosity, laser focus toward problem-solving, and a rare ability to pilot rapidly — getting proofs of concept up in weeks usually. Fast forward to today, and he’s consistently building algorithms for our venture-funded ML companies, and his work alone has contributed to the highest dollar amount (by far) of anyone on the team towards funds raised and IP within our portfolio companies.
But when I say adaptability, I’m not just saying language but overall.
For example, I’ve also hired a senior developer that’s a polyglot. But he wasn’t willing to change things up based on the situation, so it was difficult for him to fit into certain teams and also in smaller projects that required more out-of-box thinking with off-the-shelf solutions.
It took me a lot of years to realize that the key trait of a long-term hire is being able to adapt to different languages, teams, and situations. Guess what, it’s the same trait that makes a founder, designer, biz dev, marketer successful as well, so in the end, the message is this — don’t put talent on a pedestal because of their resume, raise them up when they rise above unforeseen challenges speedily and creatively.
6. The dirty secret: QA can easily become your biggest cost.
I’m not just talking about QA testers, but the reality that any QA budget is half testers and half developers fixing what’s found, both of which can easily explode in costs.
The biggest cost on the testing side is simply human limitation. If you ask manual testers to test both new features and old features (regression tests), to cover the app in its entirety becomes exponentially more expensive with each release. To combat that, we introduced automated testing so that whatever was repeatable could be done by code, letting manual testers focus on new tickets.
The biggest cost on the developer side is having to fix regressions. The most common complaints we’ve gotten from clients is new features breaking old ones. I’m not going to lie and say this never happens anymore either, it does. But after introducing automated testing and measuring our developer performance by how many times QA cycles are required per ticket, we’ve been able to reduce cost substantially.
TLDR: Automate what you can even if the upfront investment is greater, and incentivize developers for damage-free shipping.
7. Lastly, look in the mirror — that’s who this all hinges on.
I admit again, this hasn’t always been my or my company’s message. We used to cater to folks that were too busy to be hands on with their products. But looking back, all of our multi-year growth partnerships came from clients that cared intensely, got their hands dirty, listened and adapted, and hired us not to replace themselves but to add something they didn’t have.
If there’s one thing I know now, it’s that I, the founder, am 100% responsible for my company’s outcome. For hiring the right people and cutting out the poison quickly, escalating & de-prioritizing features or initiatives based on data, making sure the important lessons from failure get engrained into my next big decision. No one else can assume this responsibility, no matter how much I wish that weren’t true.
If you want to find success with app development, become a great leader. Find the right team to be an extension of yourself. Then and only then, hold onto the rocket ship for dear life.
If you feel like we might be the missing piece, let us redefine what a technical partner can do for you. Reach out and tell us what you’re working on, and we’ll share everything we know. No smoke and mirrors, we’ll tell it like it is and let you know if we think we’re the right team to take you to the promised land.
