Could $100,000 and the right developer(s) be your path into the billionaire club?
Slack was initially built as an internal tool for video game developers. After they closed shop in December 2012, a subset of the team built out Slack into a standalone product and launched it just nine months later. The business communication app quickly took off and reached a $1 billion valuation in just over a year—making it the fastest company ever to achieve “unicorn” status.
Ok, well, there are a few minor footnotes: Slack did raise $16 million, the internal tool Slack was based on already existed, and there was probably some luck involved with its meteoric growth.
But the question remains: Could you build Slack from idea to launched product with $100,000? If not, how much would it cost? How hard is it to build messaging app anyhow?
Turns out, developing apps is much more complicated than it looks on the surface.
Below, we break out four costs you’d want to consider in building a messaging app:
- Planning costs: determining what to build first
- Fixed costs: what goes into creating a Slack MVP
- Maintenance costs: apps aren’t something you can “set and forget”
- Hidden costs: important expenses that are hard to quantify
Messaging app planning costs (or debts, your choice!)
Instant messaging seems relatively straightforward: A bunch of people can send messages to each other.
You might envision a data model made up of users and messages. Maybe even rooms that contain users and messages. Either way, it really doesn’t seem all that complicated.
Or is it?
Consider these questions:
- Do you want to notify everyone when a new message is posted to a room?
- Do you want the sender to receive read receipts?
- Do you want users to communicate directly with each other?
- How do you control who accesses a room?
- Can some people see comments but not post any messages?
- Who can invite new people to a given room?
- How are payments processed?
- Should you turn off an account after one missed payment or give them a grace period?
You might think you can easily answer these questions with a “yes” or “no”, but half of the challenge is thinking through these scenarios before you start development. The other half of the challenge is finding balance. You don’t want to err on the side of leaving too much out; that’s how you build “minimum viable crap”—barely functional technology that doesn’t deliver value to customers. Neither do you want to waste months (or years!) putting too much into the first version.
The first option—leaving a lot of stuff out—might sound nice. After all, fewer features equals a lower upfront cost. But consider it from this angle. If you skip a load bearing beam when building a house, you’d be perfectly fine until you want to build a second story. The same is true for software development! If you leave out a key piece, it could cost you double (or more) to fix it down the road.
On the other hand, if you add everything and the kitchen sink to your messaging app, you could be wasting money building and maintaining features that nobody wants to use. This often looks like a founder spending months and tens of thousands of dollars adding sexy features, without ever confirming the customer wants them. This is dangerous (not to mention insanely expensive) because every decision you make early on can ripple into an oversized impact down the road.
The ideal scenario? You want your first version to be as simple as possible, but still be well-designed enough to accommodate constant change. Or, what we like call a minimum loveable product (MLP).
These aren't easy to build. Simple takes a lot more work than complex. When we partner with new clients, we spend a full day in person discussing high-level points. Then we spend even more time on our own researching the best solutions for the problem. (These are called Roadmapping Sessions—check ‘em out!)
Simple takes a lot more work than complex.
Krit
Is all that really necessary?
If you skip the planning stage, you can probably get a product to market more quickly, but you'll have less confidence it's the right product. What's more, you will incur what’s known as technical debt—the cost of redoing something because the original solution was a poor one. Meaning, you will eventually need to rewrite code you’ve hastily written or spend more time on maintenance and scaling than feature development.
So, how much for planning? If you do this by yourself (here’s a step-by-step how to), it’ll cost you time and energy. If you’d benefit from outside guidance or developer’s input, our Roadmapping Sessions cost $3,500.
Getting a little technical—what goes into building a messaging app?
The tricky part of all that planning is figuring out what's most important in your big, aspirational list of ideas. There's a lot you could build. What should you build?
A quick Google search for “build a Slack clone” shows several tutorials discussing how to build a copy of the app in different frameworks. Even if they are 100-page tutorials, you could probably get it done for less than $100,000, right?
Maybe. Let’s first take a look at the technology involved:
- Authentication: You need a way for customers to sign-up and sign-in securely. If you think that's an easy task, one developer looked at commonly used authentication tutorials and found that most were incomplete or made a major security mistake. You better know how encryption works or who you can trust to handle security
Front-end: Customer expectations are higher than ever. They expect responsive interfaces, and God forbid they have to wait more than 100 milliseconds for a page to reload. This requires a front-end framework, such as Facebook’s React framework, in addition to a back-end system, which at least doubles the amount of work involved. You may also need an iOS and Android app—which will each cost as much as the web front-end, if not more, to build out. (Whether these other apps are required for an MVP depends on the users' requirements.)
- Back-end: Instant messaging involves sending a lot of data in real-time. You can’t have one person send a message, save it to a database, and then rely on the other guy to query the database for messages every couple of seconds. Instead, you need to have each computer “subscribing” to updates from the others and anyone sending a message “pushing” it out. That’s a much more complicated process than a simple news or ecommerce website that uses a standard database.
- API Integrations: Slack’s utility lies in its integrations with hundreds of other platforms, like Giphy. That way, you can receive an instant update when Jen from Sales closes a new deal with a 100% uptime SLA…and another one from Sam in Operations saying there’s smoke coming from the server room. These integrations must use different third-party APIs that are constantly changing, which means that you need to be on top of those changes at all times. It's probably not necessary to include all integrations (or even any) in an MVP, but the decision will depend on the users and their needs.
These are just some of the technology considerations happening under the hood. It doesn't even include all the nice features that, well, make Slack so nice to use. A tutorial can probably help you build a basic working model after a lot of frustration and hair-pulling (many tutorials are outdated and painful to use), but you will still be quite a ways off from a product you can actually put in front of customers.
Give it to me straight: How much to build a messaging app like Slack?
So, what does all this mean in terms of dollars and cents? How much do you need to shell out to be a billionaire? There’s no easy answer to the second question, but we can help with the first.
We scoped out a Slack MVP to see how much it would cost to outsource development, once you’ve done some groundwork like coming up with the idea, identifying your customer base, and raising some money.
What counts as a "Slack MVP?"
If you’ve come across the acronym MVP before, there’s a 50/50 chance you have a bad response to it. That’s because a lot of people use the idea of an MVP as an excuse to launch a really crappy and barely functional product. That’s a terrible strategy, and it’s not what we’re talking about here.
When we talk about MVPs, we’re talking about MVPs done well. Those are the MLPs, or Minimum Loveable Products, we mentioned earlier.
To figure out what should go into the MLP, we started by coming up with a list of every feature you might be tempted to include in a Slack-like app, ranging from creating an account and changing your password, to filtering channels and creating custom hotkeys.
We then separated that massive list of features into MVP Features and Declined Features—or those that wouldn't be included in the initial version.
Determining the fixed costs of a Slack MVP
The next step was breaking down these features into design, backend, and frontend tasks and then adding up the total hours.
- Design tasks would take about 144 hours at a cost of $21,600.
- Backend tasks would take about 366 hours at a cost of $54,900.
- Frontend tasks would take about 246 hours at a cost of $36,900.
- Site marketing would take about 60 hours at a cost of $9,000.
So, how much for the MVP? The total cost comes out to $122,400. We also typically add 20 to 30 percent to this cost as a buffer to account for any uncertainties that arise. This pushes the Slack MVP up to around $153,000 in total.
Plus the $3,500 you spent in planning, making the total costs to date $156,500.
Keep in mind actually building this would take several months. So you've now spent around $153,000 and several months developing the app. If you want a mobile front-end, you could end up spending hundreds of thousands more to develop iOS and Android versions of the front-end.
Note: While this is a slimmed down version of the Slack we know today, it's still a very robust product. We don't recommend you commit to building something like this right away. Instead, start by testing a leaner version with customers to validate/in-validate your idea. No-code prototypes, productized consulting, or simply talking with customers are all great places to start.
Don't forget: maintenance costs for maintaining a messaging app
Any apps you build also need to be maintained, for a variety of reasons:
- Apple might change the way iOS works, requiring an update to the mobile app
- One of the third-party libraries that you use in the back-end (such as payment processing) may change and require an update.
Common scenarios like these add to ongoing costs.
More importantly, as customers start using your product, you’ll get a clearer picture what features actually deliver value to them. And chances are, it won’t be what you thought. In an interview with First Round Review, Slack’s CEO, Stuart Butterfield recounts, “The pattern was to share Slack with progressively larger groups. We would say, ‘Oh, that great idea isn’t so great after all.’” Simply put: if you’re listening to customers, your product should change over time. Making those changes will require ongoing access to developers.
If you're listening to customers, your product should change over time.
Krit
Finally, there’s dev-ops costs. If your app is successful, you’ll need to support a lot of concurrent users, which can be a technical challenge of its own. In fact, Slack struggled with these challenges as it was scaling its business! These costs—and server costs—also factor into maintenance.
So, how much for maintenance? Maintenance costs, like development costs, vary widely. Our maintenance packages range from $3,500 to $10,500, with the option to purchase 25 hour or $3,500 increments.
Other hidden costs you should know about
Building an app isn’t as simple as coming up with an idea and handing it to developers. (Wouldn’t that be nice?) There are also enormous costs on the founder. But because these costs are difficult to quantify, there’re not often mentioned. Here are some of the big ones:
- Time: validating your initial idea, interviewing as many customers as possible, promoting your product, making decisions, and building processes takes an enormous amount of your time.
- Energy: the same items that demand your time also demand your energy. And if you’re working a full-time job, not to mention raising a family, that time is already limited.
- Relationships: when you’re re-directing so much time and energy to a project, your existing relationships can—and often do—suffer.
- Health: while starting a product can certainly impact your physical health (loss of sleep, effects of stress) it mainly does a number on your mental and emotional health. You're making big decisions with high pressure and limited resources. This causes a lot of anxiety, stress, and emotional conflict for most founders.
- Personal finance: even if you raise VC money, you'll probably sink some of your finances into building a product. It's not uncommon for founders to go into debt.
Is there a dollar sign we can put on these? No. What each founder thinks their time, energy, relationships, and health are worth will vary wildly. But because they all impact how you function—both as a founder and person—they’re important to consider.
Here’s the bottom line: it's hard to build an app
Developing apps is much more complicated than it looks on the surface and costs quickly add up. That's why it’s important to invest in the planning process before you commit to building an app. We believe in this so much we dedicate a full day to in-person meetings and weeks or research following that meeting. It’s the most important part of the build process.
From there, you can reduce costs by narrowing the features you want to the bare minimum. To determine which features are the most valuable, you should focus on getting a product in the hands of customers as soon as possible and rely on their feedback to improve over time. That way, you’re not spending $100,000 adding API integrations or other features that customers don't need.
Want more honest insights? Sign up for our no-BS, free newsletter for busy founders. You'll get actionable, bite-sized lessons on building tech startups, delivered straight to your inbox every Wednesday.
Update note: This post was originally published August 2018 by Justin. We updated it December 2019 to include more resources and guidance. Think it’s still missing something? Let us know on Twitter.
