There are certain things you should never skimp on. A fine suit. A quality mattress. Your code. Sure, there are affordable workarounds to build a digital product, but like an off the rack pick from Men’s Warehouse: it might look fine from far away, but exert any pressure (or take it to the dance floor) and it might start coming apart at the seams.
We’ve seen one too many founders fall for the allure of cheap and live to regret it. So here's a primer on the pitfalls and promises of budget development.
Recognize yourself?
If this sounds like you:
- I’ve got a product in market and some funding, so I’d like to level up
- I’ve built a scrappy v1 on a cross-platform, no code, or low code solution and I’m looking for PMF
- I’ve built a product on one platform and want to translate to another
- I’ve built with another agency; it didn’t go well – HELP!
Then the transactional nature of the dev shop relationship probably won’t get you where you need to go.
The Dev Shop Problem
“Budget development” has its time and place for many early stage founders, but it's worth understanding when this decision becomes a time and money suck. Dev shops are great at:
- Code implementation and technical development verbatim to provided PRDs
- Shorter term launch timelines without strategic, growth-oriented, post-launch vision
- Operating as a contractor, brought in for a singular task – development
No shade to dev shops: these are all necessary functions, and, in some cases, pay-to-code solutions are absolutely the best wrench for the nut you’re trying to loosen. The problem is that often founders or teams looking for support on a product get talked into a quick fix when what they need is a digital partner.
The Siren Song of Budget Development
Cards on the table: the kind of partnership you’re going to get with a full-service agency isn’t cheap. When you try and compare apples to apples (as in: how much am I shelling out right now to solve this problem?) a dev shop is going to win, every time. But cost is just one variable worth exploring:
Infrastructure and Scale
If you don’t know how to ask for scale-ready infrastructure, a dev shop isn’t going to give it to you. Even if you do ask, they may or may not have the know-how to provide it without things getting a little messy.
Why?
- Dev shops are often on a fixed scope, they want to deliver within a budget and on time, even if they have to sacrifice quality to get there.
- They’re going to get you to something that works, not necessarily something that can grow.
Often these products can’t handle an uptick in scale without a complete rebuild, which leads to more of a financial outlay and future technical debt. So, you might pay less on the front end but end up saddled with a product that can’t grow without starting over.
Platform & Code Quality
Another casualty of budget development: your code. Dev shops often use low-code or simplified cross-platform solutions that are highly limited. Which makes them limiting, when it comes to innovation.
Their MO is to look for fixes to solve present, visible, problems quickly. They’re not as concerned about the long-term problems those quick fixes cause down the road.
You end up with a “what you see is what you get” product that might meet your needs today but will be obsolete before you walk out the door.
The Multi-Platform Mistake
Our perspective: if you’re early stage with your product, building on two or three platforms at once is a mistake. (File that under: other things dev shops won’t tell you.)
Here’s a scenario we see a lot:
- A founder builds on iOS + Android + web simultaneously
- They make a mistake
- That mistake gets replicated across all three platforms
- Then they have to pay, also across all three platforms, to fix that mistake
Founders need someone in the room who can steer them away from costly mistakes - a partner in the process.
So why would anyone choose a dev shop?
Put simply: budget.
Add to that gaps in leadership and know-how, including:
- Missing product guidance
- Limited technical leadership
- Too much focus on immediate cost over long-term viability
- Mistaking internal domain expertise with digital product strategy expertise
- Uncertainty/lack of metrics on product market fit
For some founders and companies early in their product lifecycle, a dev shop might actually be the right solution. If you’re in the earliest of early stages – the “scrappy” phase of development – and you have a small budget to prove out product-market-fit before you attempt a raise: a dev shop isn’t a bad idea. They’ll get you a workable product to start to gather user feedback and take next steps.
So, if that’s you: go forward and get an MVP in the works. But if it’s not, then don’t let fear of cost turn small gaps into uncrossable chasms.
Taking the right approach to development
Though the “right approach” might be subjective, at Studio we believe there are three immutable laws for good product development:
- Build the smallest possible version of every feature/product
- Avoid designing and developing in a vacuum (at all costs)
- Gather actual user insight as quickly as possible by getting to market fast
Our clients share these beliefs. Or if they don’t yet, they trust us enough to lead them there anyhow. That’s the kind of guidance we offer, and our clients rely on it to solve complex problems and get products in users’ hands fast.
Founders who are waffling between these two options (dev shop or studio) should think long and hard not just about cost, but the kind of partner they want. One who will do exactly what you ask, and add little to no strategic advice? Or the one who’s going to stand shoulder to shoulder with you deep in the weeds?
We know what we’d choose.