What I learned failing to outsource an MVP
Why every founder should become technical
Shortly after graduating college I had an idea I was super passionate about and figured what better way to test it than putting it into customer’s hands. The path was simple, build an MVP, acquire active users then raise capital and I’ll have made it to the promised land of Silicon Valhalla.
If it was only ever that easy…
I thought to myself, websites had been built thousands of times, maybe even millions, thinking I was pretty tech-savvy myself because I’d been reading tech blogs for over 10 years thus I figured I’d be up for the task of making this happen. I decided it would be the best use of my time to outsource rather than learn to skills in building it myself to expedite myself out of the idea stage.
How little did I know then about software development at the time to think outsourcing was just as straightforward as hiring a development team. Beautiful can the naivety of youth be.
Sequence of Events
I spent one month writing a business plan (that was never opened again), then spent many months making hundreds of user flow journeys (with Adobe XD) until I thought I got enough of the idea out of my head.
After crafting the visuals, I proceeded forward with making written documentation, a centralized notion document that was neatly hyperlinked with all other mentioned features all spoken from first principles written in scientific lab report prose borrowed from my physics + chemistry undergraduate days. It was the utmost passion one could have in making something as mundane as product documentation but it was what I thought I could do best at the time.
With the documentation finished, I began interviewing developers, initially starting with solo developers until being told it was too large of a task for any single developer (in retrospect a massive lie just lazy developers wanting easy projects to cash out on) to build in a reasonable time frame (under six months).
Then I started looking for highly rated development firms out of Eastern Europe with many search terms like “best software development agencies in eastern europe” until stumbling across the infamous clutch.co list that I would spend many hours scrolling through. Eventually, I expanded my search outwards into South America and Asia, in totality having interviewed development teams between the US, Romania, Poland, Estonia, Latvia, India, Pakistan, and probably a few more countries I’m not remembering. It took over six months of interviews to come to a decision, but once the contract was signed, there were about four months of development in total.
I got many things wrong but in the end, I ran out of starting capital (acquired from a drunk driver accident) and got left with an unfinished product unusable for validating my market hypothesis.
What did I learn and what did I do? I bit the bullet, learned to code, and built the entire product myself after many heated conversations with the abyss. Retrospecting in hindsight after becoming a technical founder, I’ve got a few tidbits of wisdom to share below.
Better Tech is not Always Better — Flutter
Before seeking quotes from software agencies, I made myself acquainted with the many technologies at the time (mid-2021) narrowing the search to cross-platform technologies like Ionic and Flutter, though React and Angular were also considered. I was quickly seduced by the Flutter mantra of, “write once, compile everywhere” which technically was true but missed the nuances of real-world software development, specifically the ecosystem of libraries and packages.
The trade-off from the non-technical perspective seemed that fewer developers could use cross-platform frameworks like Flutter but since I was starting with a fresh codebase this seemed to be a huge opportunity to get a leg-up on my competition. Yeah… very many things wrong with that analogy but I stuck with this intuition only to discover finding Flutter developers was not an easy task.
Still, I was completely dead set on using Flutter (Flutter Web and Mobile) so I could launch across web, desktop (not initially but eventually), and mobile with relatively minimal effort, irrespective of how many web developers tried telling me it was not going to work the way I thought it was going to work. Their skepticism only emboldened me as I saw the friction of working with this new technology as a massive opportunity, a test of my grit whether or not I could find the team that could make it happen with this tech stack.
What happened in the end?
One of the core features required interacting with PDFs, once using the product I was horrified to discover how finicky text selection was, failing 30-50% of the time in my use. I became furious once realizing this was not a development quirk but rather the reality of the implementation. I started doing research into PDF renderers since that seemed to be the source of the problem, only to discover there were very few PDF renderers written in Dart, if any at all. After discussing with the developer team, the only solution seemed to be rendering via PDF.js within Flutter Web instead of the native Dart PDF renderer, nearly doubling the overall initial budget to then mirror that functionality on mobile as I would it would have to be a separate development effort for Flutter mobile. The reason why text selection was finicky is because Flutter Web renders on the canvas and not on the DOM then tries to inject a DOM element where you might try to select text.
Stick to the tried and true web stack (React + NextJS) for an MVP always, better is not always better.
Outsourcing Mechanics and Personal Failures
Part of the reason why it took six months to find a development team was due to the inherent friction with communicating with development teams in time zones transcontinental to yours. Typically communication begins with with some introduction email off of the development firm’s landing page with a turnaround time of a few days for the first introduction email. The next step was sending an NDA, not that it protects your idea but it’s a means of building trust with a potential partner, if they don’t want to sign it’s a red flag for certain. Waiting for the NDAs to be signed by both parties would take 1-2 weeks, sometimes they’d ask for revisions or clauses to be removed in that interim period. After that, there’d be 1-2 calls, typically an introduction call followed up by a technical deep-dive, then hearing back with an actual quote and estimated development time.
From sending the first introduction email to a quote, it would take about a month on average. These development houses have to tender their existing contracts so you’re put on the backburner as a new client. A lot of these development houses would try to bundle design services or have you do an idea-exploration phase session with a product/design person, upsells that a hungry founder has no resources for. In totality, it was a massive waste of time, it made sense for me at the time but if I could do this again I’d have rather spent those six months learning to code. That also means you get out of Udemy tutorial hell urgently, unlike my earlier attempts at learning to code where I stopped right before reaching lift-off velocity.
Putting all the mechanics and misalignment of incentives of contracting aside, the contract I negotiated with the developer was not milestone-based for payout but it did have a hard cap on budget alongside the firm feature requirements and tentative delivery schedule. The contractor’s justification against milestone payment was that the team of developers on payroll could not be jeopardized in missing payment if they were late on a feature delivery due to unknowns they were unable to anticipate, but that an earnest attempt would be made to follow the approximate timetable that was set up.
In retrospect that justification was bullshit, any developer worth their salt and who enjoys programming will validate the code and get a proof-of-concept working before taking on any project. If they’re any good, they’ll want to work on a fixed budget not hourly, betting on their ability to finish sooner not later, that’s the payout method I’d pick myself. Any contractor that wants to be paid for research also should not be considered, most of the work you do in software is reading, and the actual coding is probably less than 10% of the work. That’s just another low-hanging cash grab.
Build Once Fallacy
The fundamental problem with software is that it’s never built once, software is rebuilt seemingly to no end. Startups are no different, you need to be able to pivot at the drop of a dime and it’s nigh impossible for any founder to have the intuition to perfectly predict demand and what should or should not be built ahead of time.
Outsourcing software development ossifies your thinking, both in terms of scope and vision as you’re solely interested in getting the most utility out of your capital. One tries to then cascade development, minimizing the time “lost” in rebuilding any part of the stack. Outsourcing can work, but the margin for error drastically minimizes as you have much fewer opportunities to swing the bat of estimating consumer demand.
Once I became technical, I was never going to skimp on the quality of the product and if a newer better technology became available while building, I’d swap to that at a moment’s notice if time permitting. A founder will not hesitate to rewrite and rebuild software if it results in a better product and user experience and no software contractor will ever have the same passion for optimizing the experience to the final 1%.
Learning to code enables the vision to take precedence, letting the mechanics of software development dissolve in the background. You no longer ration what features should exist from a list of features you deem core to the product, one simply builds it all without compromise, letting your will be the limiting reagent.
Finding Developers
Here’s an unspoken truth in software, most developers don’t love what they’re doing, they’re solely interested in a paycheck so they can go on and get the things they want done out of life. This remains true with most jobs people work, but why might this be the case in the field of software? Most developers are maintaining B2B software products, much of the time either backend databases or dashboards that follow very specific business logic. They’re rarely ever using the latest software stacks or trends mostly because they need to maintain legacy codebases they never started.
You don’t have to pay anyone who truly likes building software to code, just looking at the sheer number of open-source software on Github will tell you everything. Your role as a founder is to bring excitement to a potential cofounder and or person building your product, if it’s truly a captivating vision they’ll build it without hesitation. Obviously the time allocation for building pro bono varies by person and circumstance, but the point should be made clear by now. Start looking in places where developers talk about code in their free time, discord channels of popular coding YouTubers are going to be a prime target to find exactly that.
Conclusions
Building anything that does not exist is hard, when venturing into the unknown ideally you want to have as much agency as possible, and outsourcing as a non-technical person is extremely risky. The last variable you need to take a risk on is the underlying technology, make your life simple, and stick to the web technologies as it is the most documented, tried-and-true tech stack of them all. Don’t take that advice as gospel, some of you might be building mobile apps or something else very specific but as a general principle stick to web technologies if possible. Now that I have developed engineering skills, I could entertain outsourcing again but only within a limited scope and feature solely for saving my own time.
The biggest problem with outsourcing as a non-technical founder is the sense of helplessness when you’re forced to wait having little to no influence to alter the course of events. You’re then forced to further rationalize instead of generate, when I learned to code I got much more creative and it drastically helped me clear up the vision of the product by not having to “ask” or down-regulate my requests into easier-to-build features. What became my biggest insecurity for the longest time became a point of strength, setbacks became challenges that I could overcome and learned to embrace.
Once you become the builder, time will dilate around you in your trance and it is exactly then when the magic happens.
The time to generate is now — t3gin
If you liked what you read feel free to give me a follow on Twitter/X and subscribe below. If you have any questions my DMs are open.