Many people envision a tech startup founder as a college student in a hoodie coding in front of a computer screen late into the night.
After a montage of sleepless nights, Mountain Dew and beer, the founder launches the app, it catches on like wildfire, and the rest is history. It’s a great plot for a movie, but most successful apps aren’t quite as dramatic.
Most successful tech startups were founded by experienced business people that brought their idea to a development shop or assembled their own in-house development team to make it a reality. They have a deep understanding of their target market and a good idea of what the product should accomplish, which is really more important than the technical skills required to build the actual product.
Technical teams take a lot of different approaches to building these ideas into an app. Our process is inspired by Thoughtbot’s Playbook and other opinionated frameworks, as well as our own experiences as both startup entrepreneurs and developers working with other entrepreneurs. The lessons that we have learned along the way can help you avoid many of the common pitfalls of app development (mistakes we’ve made ourselves) and increase the odds of success.
Setting the Stage
Many clients are experts in their industry and have a grand vision for a product. If they were trying to build a vehicle from scratch, they envision a Tesla Model S that could take decades to design and build, instead of a go-cart that could be built in a month.
It’s great to have a long-term picture in mind when building an app, but it’s important to start much smaller. For example, Groupon began as a customized WordPress blog where the founders would manually post daily offers, generate off-the-shelf PDF coupons, and email them to customers using a simple script and Apple Mail. While this wasn’t a very scalable solution, it proved that people would be willing to pay for coupons with little upfront investment, and the company went on to go public.
Along the same lines, Facebook helped connect college students at Harvard long before your mom and dad started snooping through your timeline.
We strongly recommend that our clients take a Lean Startup approach and build a minimum viable product—or MVP. The idea behind an MVP is that it contains the minimum number of features to be a viable product that customers will pay to use. By starting small, you can increase your immediate return on investment and avoid building unnecessary features.
We meet with all of our clients in person for a paid roadmapping session to help them along this path. We start by writing down every possible feature, then pare this list down to the smallest possible MVP during a whiteboarding session. We make sure to be very granular about what goes into the MVP while making the time and cost tradeoffs crystal clear—trade-offs that may not be intuitive for those without engineering experience.
Refining the Idea
Most people don’t realize that the most important parts of the development process happen before any code is written. Before we write a single line of code, we want to be very clear about what we’re building, why we’re building it, and how it’s going to be developed.
The most important parts of the development process happen before any code is written.
Suppose that a client wants to build an instant messaging app. During the roadmapping session, we would ask the clients granular questions to understand the scope of the MVP: Do they want person-to-person messaging or group chat rooms? Do they need read receipts? Do they need notifications? Do they want to store the data? We can then start to envision the functionality that will be required and how the screens will look on a basic level.
We then sketch concepts on a whiteboard to iterate quickly on ideas without getting caught up in the details. This gives us a good idea of the various screens that will need to be created on the front-end and helps the client see how the pieces fit together. We also have a basic idea of the elements on each screen, which helps us start to think about the back-end data model.
We also start to explore the technical implications of these decisions in the research phase. For example, we might ask ourselves what third party tools could reduce development time?
All of these little architecture decisions made early on have a huge impact down the road in terms of the upfront cost to develop and the long-term technical debt—or, the complexity of changing things down the road.
Wireframes & Mockups
We start the design process with information architecture and wireframing. At this stage, the last thing we want is to get bogged down in the details of design, which a high fidelity mockup is sure to cause. Low fidelity wireframes help us get to the core of the functionality with the client, before moving on to stylistic and design decisions.
Wireframes are more about what will appear on various screens rather than how these elements are positioned or styled. In other words, we want a clear idea of how a user is going to move through the app and what the most important information is at each step.
After developing a clear understanding of user flows with wireframes, we apply styles to them to create mockups. These mockups are visually appealing to users, but they shouldn’t be overwhelmed by the features or require any training to use.
We load these mockups into Invision and put them in front of the client’s users or investors to collect feedback. The goal is to discover any major changes early on—before writing any code—to minimize costs and maximize time efficiency.
The Development Process
We typically begin working on the backend at the same time as the mockups.
After looking at the wireframes to see how data will flow through the application, we start documenting what the code will do before writing any. The idea is to develop a clear picture of what the backend will do and then we will have a better vantage point for writing the actual code to accomplish those tasks, as well as a much clearer roadmap to get it done. It also gives our front- and back-end developers a chance to get on the same page before any code is written, so we don’t have to go back and fix things down the road.
When writing code, we use test-driven development (TDD) to minimize any errors and keep the code base as lean as possible. This means that we write a test for a given piece of functionality (e.g. filling out a sign-up form creates a user in the database) and then write the actual code to make the test pass. That way, we can avoid creating any unnecessary functionality and keeps bugs and issues to a minimum as the app grows more complex.
The downside is more code often translates to both higher upfront cost (e.g. more hours to write) and more technical debt (e.g. more complex to change down the road). So we strive for balance. We don’t necessarily write tests for everything—that would take up a lot of billable hours—but we have a solid base that ensures that the app is stable and lean.
At the same time, our frontend developers begin by creating all of the user interface components and putting them in a sandbox that anyone on the team can access. They can then work on building out the actual screens while drawing from those reusable components in order to ensure a consistent user experience and minimize development time.
Think of it like getting ready to cook a big meal. You can haphazardly pull ingredients out of the cabinet as you need them, leaving them strewn all over this place. That works, sure. But professional chefs spend hours beforehand chopping ingredients and getting them ready so that they can focus completely on cooking and everything runs smoothly.
Deploying Early & Often
We believe in deploying code frequently rather than trying to get everything to a “done” state. That way, you can get the app into the hands of users more quickly and discover what they like and dislike, as well as any errors that may need to be fixed.
But, that doesn’t always mean that users will be seeing new features. Many deployments are backend heavy, which means that clients may not see what has been done, but they may contain refactored code (e.g. code that’s rewritten to be more efficient and concise) or new functionality behind-the-scenes. Mobile apps may also require approval before they’re deployed to the Apple App Store or Google Play.
Ready to Get Started?
We specialize in helping non-technical founders at B2B startups turn bold ideas into incredible products. If you’re spending too much time on technical problems, and not enough time in areas where you can make a difference, let’s talk.
If you’re just getting started or looking for more advice, check out our newsletter for busy founders, where you’ll find weekly, bite-sized lessons on building tech startups.