For new, and even seasoned entrepreneurs, presenting an app idea to a developer is a process fraught with misunderstanding. You don’t have to be a programmer yourself to present clear ideas to a development agency.
In fact, founders are better off focusing on management and business skills than tech. Nonetheless, learning more about how this process works can save you a lot of trouble and get you far more accurate estimates.
Here’s the TL;DR; in three quick rules:
- Stay tech-stack agnostic until the very last moment
- Think in goals and user stories
- Make a user journey
The Zen of being a founder
The old saying that a little knowledge is a dangerous thing is especially relevant for startup founders. Reading a few pop-tech websites or even doing some online coding courses does not an engineer make. I’ve seen this play out plenty of times when a non-engineer decides that some hipster tech stack is the only solution for their app.
This is the exact opposite of the Zen beginner’s mind:
In the beginner’s mind there are many possibilities, in the expert’s mind there are few.
Shunryu Suzuki
Be careful of artificially closing your mind at an early stage. This not only prevents you from getting seasoned advice from mentors, it raises the possibility of your app becoming a monstrous Rube Goldberg machine.
I don’t mean to dismiss the latest JS framework, newest blockchain or advance in machine learning—we use all of them at eTeam. The difference is that we have engineers with collective decades of experience analyzing how to solve problems. The difference is subtle, but it leads to the next fallacy.
Solutions looking for a problem
When you choose a tech stack too early on your path from idea to MVP, you risk solving problems that your app doesn’t actually have. I’ve heard the refrain hundreds of times that we have to switch to [language/framework/database] because it’s [faster/scalable/sexier]. Each time I have the same response, “What’s your current [speed/scalability] problem?” Oddly enough, I often get blank stares.
As founders, we’re not immune to market forces. Slick copy and nice stock photos work on us, too. For the same reason that I don’t buy a new iPhone each release cycle—I can do 99.9% of what the new phone does on last year’s, jumping to each fad tech stack is expensive with relatively low return on investment.
None of this is to say that you shouldn’t be concerned about scalability, speed and emerging trends. There’s a soberness to “My app is going to process a million transactions a day and [language] is the best choice to handle that type of load.” That’s very different from “[Language] is cool, so I want my app written in it.” You’d be shocked how often I hear something along those lines from people that ought to know better.
Thinking in goals
When you present your app idea to an engineer or development agency, it’s easier for everyone if you present your idea in terms of goals or accomplishments. The more concrete you can get, the better. Telling a developer that you need an app that is fast and scalable is essentially useless.
Instead, have the main use cases and some real numbers ready. My app is going to be used by parking structures in a mid-sized US city to process payments. Data has to be processed instantly so that security guards can verify that a car is parked legally. Our initial market will have about 10,000 transactions a day, but we plan to expand to other cities.
This is relevant information that a solution architect can use to design the appropriate architecture for your app. It’s still important to remain tech-neutral at this stage and evaluate your different options from a business perspective.
User stories and personas
Thinking in goals is more general, defining personas and user stories makes your goals more specific. Simply put, a persona is a your target user, and there can be multiple personas for a single app. A user story is what those personas do. Anything can have a user story, even this blog post!
As a (here goes your persona) non-technical founder of a startup (and here’s your goal) I can learn how to better present my app idea to an engineer.
Breaking down your app into overall goals and user stories is really helpful for developers that need to understand your project, scope it out and craft a proposal.
Go for the full user journey
Photo by Kaleidico on Unsplash
An even more in-depth look at how someone would use your app is a user journey. Here, you map out the entire path someone would take when they use your app. This requires little more than a thorough understanding of how you your app is going to work and some simple mockups, even quick hand-drawn sketches can do the trick.
Creating a full user journey can unearth some engineering requirements that you hadn’t thought of before. If a user needs to select something, this forces you to consider where that something is coming from—your own database or an API. A user gets a notification, is this a push notification, email or text message? Going on like this, map out every possible scenario a user would go through. This user map will be invaluable when it comes time to make a detailed proposal.
Proposal time
Once you have your user stories cleaned up and a user journey all set, you’re ready to present your ideas to a developer. Presenting your app idea like this will get you a faster and more accurate proposal. I’ve seen cases where proposals can vary by 50% or more because assumptions have to be made or key features are excluded from the proposal because they weren’t uncovered in the user journey.
If you don’t have all of this information ready, less scrupulous development agencies will give you a completely unrealistic lowball proposal. Once they’ve already begun working on your app, they’ll start adding features that should have been uncovered with a strong user journey. This can easily double the cost of your too good to be true proposal.
Talking tech stacks
Now is the time to look at tech stacks and choose one that solves all of your problems and fits in with your organization’s goals. At eTeam, we’re big Ruby on Rails and React Native fans, but there’s often more than one solution out there. For specific client needs we’ve worked with Node, Python and PHP. Even dedicated Rubyists admit there really is no one size fits all solution.
It pays to shop around, get a few a proposals and then compare the solutions offered. Be ready with questions about maintainability, how easy is it to find other developers for a particular tech stack and does this stack mesh with your future plans. If you can’t get clear answers, that’s a serious red flag.
One of my favorite things about being a startup founder, is helping other founders go from idea for app on shoestring. If you have an idea that’s ready to go, I’d be happy to hear from you and help you get going on your app.
