A startup announcement captures a moment: a product launch, a new capability or an important business milestone. Looking back several years later lets us ask a more useful question. What had to happen after that moment for the company to develop?
In 2017, Monzo moved towards full current accounts, Starling brought its banking app to users, and Slack expanded the ways organisations could communicate through its product. Their subsequent histories include profitability milestones, a new software business and an acquisition.
This is a selective retrospective of three companies active in 2017, including businesses already at the scaleup stage. It is not a ranking, a list of companies founded that year or a claim that their later outcomes could have been predicted at the time.
The milestones below are dated deliberately. They show parts of each company’s development, rather than claiming to describe its complete position today.
The three stories at a glance
| Company | A milestone around 2017 | A later documented development |
|---|---|---|
| Monzo | Banking licence restrictions lifted in April 2017, enabling a phased current-account rollout | Reported its first full year of profitability in FY2024. |
| Starling | Launched in app stores in 2017 | Reported its first full-year profit and launched Engine by Starling in 2022. |
| Slack | Added features including threaded messages and shared channels in 2017 | Salesforce completed its acquisition of Slack in July 2021. |
These are different measures of progress. Becoming profitable, creating a second product business and being acquired should not be treated as interchangeable outcomes.
Monzo: the move from an early product to a broader service
On 5 April 2017, Monzo announced that its banking licence restrictions had been lifted. Its announcement described the next step: bringing current accounts to users who had previously used its prepaid product.
The rollout was explicitly gradual. Monzo said it was running live accounts with a small group before expanding access. That detail is useful because it shows the work between a major announcement and broad availability.
An early product can establish interest and reveal how people behave. Expanding its responsibilities requires evidence that the operation can support those responsibilities. In banking, the surrounding service matters alongside the mobile interface.
Years later, Monzo’s FY2024 reporting recorded its first full year of profitability, with £15.4 million in pre-tax profit. That is a dated financial milestone, not a statement about every period before or after it.
The gap between those events is a reminder to define what each milestone proves. A launch demonstrates availability. Usage demonstrates some level of adoption. Profitability measures a different aspect of the business.
The product lesson: plan the transition beyond the first release. Ask what changes when more customers depend on the service, how support will work and what evidence should justify the next expansion. An attractive interface is part of that plan, alongside operational readiness.
Starling: a consumer service and a later technology proposition
Starling’s 2022 chief executive letter described achieving its first full year of profitability five years after launching in app stores. It reported a pre-tax profit of £32.1 million for the year ending 31 March 2022.
The same letter described the launch of Engine by Starling in 2022, a software-as-a-service subsidiary intended to offer its banking technology to other banks.
Those developments make the story interesting beyond the original app launch. Technology created to run one service can potentially become a product for other organisations. That possibility still needs a separate commercial case.
An internal platform is built around the needs and assumptions of its original operator. Selling it externally introduces questions about configuration, documentation, onboarding, support and integration. Another organisation may operate differently, even if it appears to perform similar tasks.
For founders, the useful distinction is between reusable code and a product that another customer can adopt. The former does not automatically establish the latter.
The product lesson: build a coherent service first, then investigate whether its underlying capabilities solve a wider problem. If they do, treat external adoption as a new product challenge with its own users, requirements and economics.
Slack: expanding the role of a collaboration product
Slack’s 2017 product history records threaded messages in January and the shared-channels beta in September, alongside administration and enterprise-related improvements.
These changes addressed different levels of use. Threads helped organise individual conversations. Shared channels opened a way for separate organisations to communicate in a common space. Administration features supported the people responsible for managing access and deployment.
That combination illustrates a recurring challenge in business software: the person enjoying a feature may not be the person responsible for approving or maintaining the product.
On 21 July 2021, Salesforce announced the completion of its acquisition of Slack. This was a major ownership milestone. It does not prove that any single 2017 feature caused the acquisition, and the history should not be simplified into that causal claim.
For a founder, the practical question is how a product fits into the work surrounding it. Who needs access? What must administrators control? Which other systems contain information that users need? How will a team introduce the product without disrupting its existing responsibilities?
The product lesson: adoption has several audiences. Design the everyday user experience, while also understanding the needs of administrators, buyers and the teams responsible for implementation. Those requirements can become more important as customer organisations grow.
What these examples do not prove
Looking back makes outcomes seem more predictable than they were. Selecting familiar companies also introduces a clear limitation: these three stories are not representative of every startup operating in 2017.
They cannot tell us the probability that a new banking app or collaboration product will succeed. They also do not establish that copying a particular feature will reproduce an outcome.
Company announcements are useful primary sources for dated events, but their descriptions of strategy are the company’s own perspective. Read reported milestones separately from promotional language and from our interpretation of the product lessons.
The most useful approach is to turn a historical example into a question you can test in your own business.
Five questions for founders building a product now
1. What does the first release need to demonstrate?
Decide whether you are testing demand, usability, technical feasibility or an operating model. A prototype can help answer one question without settling the others.
For example, users may complete a booking in a demo while the team still needs to establish whether suppliers will maintain accurate availability. Test both sides of the service before assuming the full model works.
2. What makes the product useful again?
An initial signup tells you little about recurring value. Identify the next occasion when someone should return and what they should be able to accomplish.
Measure repeat use against that need. A monthly reporting tool should not be judged solely by daily usage. A service people depend on throughout the working day requires a different standard of availability and support.
3. What changes as responsibility grows?
More users can introduce support, access-management and reliability requirements that were easy to handle manually during a pilot.
List the operational tasks, assign owners and identify when a manual process will stop being workable. Use those thresholds to guide investment rather than treating every possible future requirement as part of the MVP.
4. Can the business support the service it promises?
Revenue, customer numbers and investment are different measures. Understand the cost of delivering the product, including onboarding, support, third-party services and maintenance.
Use a simple model to test assumptions. If each new customer needs substantial setup, include that work in the economics rather than considering only software hosting costs.
5. Which expansion needs its own evidence?
A new audience, integration or business model may require more than another feature. Selling a tool to an enterprise, for example, may introduce requirements that do not arise when an individual signs up independently.
Define what you need to learn before expanding. A successful first use case gives you a foundation, but it does not answer every question about the next one.
Build your own sequence of milestones
The value of revisiting startups from 2017 is in understanding the work between the headline events. These examples show different kinds of progress and different questions to ask about a growing product.
For your own project, define the user problem, the purpose of the first release and the evidence needed for the next decision. Then connect that roadmap to the people and resources required to operate the service.
Our guide to defining and prioritising an MVP provides a practical starting point. If you need help turning the scope into a product, explore Addbox’s mobile app development or software development services.
Plan the work after the first release
If you are turning a first version into a service people can rely on, explore Addbox’s software development services. For products that belong on a phone, see mobile app development.