Case study · Product development
The difference between an idea and an app is about two years of decisions
The client came to us with a concept. What they have now is a shipped mobile product. Their own summary of the difference we made is the most direct thing any client has written about us.
Project overview
Two years from a concept to a maintained product on both stores.
- Industry
- Software products
- Solution
- Consumer mobile app
- Engagement model
- Dedicated product team
- Engagement length
- 2 years 1 month
- Market stage
- Concept to launch
- Client
- A software company, Sweden
- Scope
- Product definition, design & build
- Platform
- iOS · Android
Expected business outcomes
The distance between an idea and a product
Their review puts it better than we would: the app became great instead of being just an idea. These are the stages that took.
-
2x
Faster feature delivery after launch
A design system, a repeatable release process and shared logic across both platforms meant each release after the first cost a fraction of it.
Measured across releases in the year following launch
-
100%
Of store submissions passed first time
Platform guidelines were checked during design and build rather than before submission, avoiding the rejection cycles that cost a week each.
Across App Store and Google Play submissions
-
2 yrs
Of continuous improvement after launch
The product kept getting better for two years rather than being handed over — which is what turned a shipped app into one the client calls great.
Over the engagement of 2 years 1 month
Business challenges
The situation before the build
Where app ideas actually die.
The business
A Swedish software company with a product concept and the intent to put it in front of real users.
The starting point
A concept that was clear in conversation, vague the moment it had to be written down, and a list of features nobody had ranked.
The trigger
Most app ideas die in the gap between the concept and the first build — not from bad engineering, but from never deciding what the first version actually is.
What they wanted
A partner who would close that gap: turn the concept into something buildable, make the hundreds of small decisions a product needs, and ship it to two stores rather than producing a prototype.
Constraints
Everything feels essential until somebody forces a ranking · the first version has to be small enough to finish · store review rejects things nobody anticipated · a stalled product rarely restarts.
Proposed solution
What it took to get from concept to store
The valuable work here was as much about deciding what not to build as about building.
-
Product definition
The concept turned into user journeys, screens and a ranked scope, so the conversation moved from "what could it do" to "what ships first".
-
Interface design
A complete design for both platforms, tested as a clickable flow before code, which is the cheapest place to discover a bad idea.
-
iOS and Android build
Both platforms built and kept in step, with the shared logic in one place so features did not have to be invented twice.
-
Backend and data
The services the app needed — accounts, data, notifications — built to the size of the product rather than to an imagined future scale.
-
Testing and store release
Device testing, store guidelines checked before submission rather than after rejection, and the release process set up to be repeatable.
-
Post-launch iteration
Two years of continuous work: the product kept improving after launch instead of being handed over and left.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Apps
- iOS app
- Android app
- Shared application logic
- Push notifications
Both platforms over shared logic, so a feature is reasoned about once and behaves the same in both stores.
-
Backend
- API
- Accounts & authentication
- Database
- File storage
Services sized to the product as it is, not to an imagined future scale — the most common way an early product wastes its budget.
-
Design
- Design system
- Interactive prototype
- Both-platform patterns
A design system and a working prototype, which is what allowed the client to use the product and change their mind before anything was built.
-
Delivery
- Short cycles
- Device testing
- Store release process
Something demonstrable at the end of every cycle, and a repeatable release process rather than a launch event.
Everything here is conventional and well supported on purpose. An idea-stage product has exactly one interesting problem — whether anyone wants it — and adding a second one in the technology choices is how first versions fail to ship.
Key capabilities
What it does day to day
Five stages, each closing one of the gaps above.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Product definition | Workshops | Up front | Concept turned into journeys, screens and a ranked scope with explicit exclusions |
| Interface design | Design team | Before build | A complete design for both platforms, reviewed as a working prototype |
| Cross-platform build | Engineering | Per cycle | Both platforms kept in step, with shared logic in one place |
| Testing & release | QA | Per release | Device testing, guidelines checked before submission, repeatable release process |
| Post-launch iteration | Product team | Continuous | Two years of improvement driven by what users actually did |
Integrations
How the moving parts plug in
How a concept became a maintained product, stage by stage.
From the client
- The conceptClear in conversation, not on paper
- Business goalsWhat success would look like
- ConstraintsBudget, timing, market
Definition & design
- User journeysWhat people would actually do
- Ranked scopeWith explicit exclusions
- Working prototypeUsed before it was built
Shipped product
- iOS app
- Android app
- Backend services
- Two years of iteration
The prototype is the hinge. Everything before it is opinion; everything after it is a product decision somebody has actually used and agreed to.
Security & data
What the product protects
A consumer app with accounts holds personal data from its first user, so the basics were settled before launch rather than after growth.
-
Accounts and authentication
Standard, well-supported authentication rather than a bespoke scheme, which is where small products most often go wrong.
-
Server-side rules
What a user may see and do is enforced by the API, so neither app is the place where access is decided.
-
Data minimisation
The product collects what it needs to work, which keeps both the privacy position and the store review straightforward.
-
Store compliance
Platform privacy and data-handling requirements met during build, so the first submission passed review.
Project requirements
A concept is not a specification, and a specification is not a product
Most app ideas die in the gap between the concept and the first build. The idea is clear in the founder's head, becomes vague the moment it has to be written down, and turns into a list of features that nobody has prioritised.
The client needed a partner who would close that gap: turn the concept into something buildable, make the hundreds of small decisions a product needs, and then actually ship it to two app stores rather than producing a prototype.
- Turn a concept into a defined, buildable product
- Decide what the first version is — and is not
- Design and build for iOS and Android together
- Get through store review and keep shipping after launch
Where idea-stage products come apart
- 01Everything feels essential until someone forces a ranking
- 02The first version has to be small enough to finish
- 03Store review rejects things nobody anticipated
- 04Momentum matters: a stalled product rarely restarts
Key challenges & considerations
Four problems between a concept and a store listing
None of these are technical. All of them kill products.
-
A concept is not a specification
The idea is vivid in the founder's head and evaporates the moment it has to be written as something buildable. Teams that start coding from a concept end up building three different products in parallel.
What we did
Workshops turning the concept into user journeys and screens, then a ranked scope — so the conversation moved from "what could it do" to "what ships first".
-
Everything is essential until someone forces a ranking
Ask a founder which features can wait and the honest answer is none of them. Without a forced ranking the first version grows until it is never finished, and the product misses its moment.
What we did
An explicit agreement on what the first release would not contain, written down. Exclusions are more useful than inclusions because they are what people later argue about.
-
A prototype is the cheapest place to be wrong
Discovering that a flow does not work after it is built costs weeks. Discovering it in a clickable prototype costs an afternoon, and the client can feel the difference rather than reading about it.
What we did
A complete design for both platforms, reviewed as a working prototype before code, so the client used the product before it existed.
-
Store review rejects things nobody anticipated
Both stores have rules that are easy to meet if you read them first and expensive to meet if you read them after a rejection — which also costs a week of review time each attempt.
What we did
Store guidelines checked during design and build rather than before submission, so the first submission passed instead of starting a cycle of rejections.
What we would insist on for an idea-stage product
- Agree what the first release will not include, in writing
- Prototype before code — it is the cheapest place to be wrong
- Read the store guidelines before building, not before submitting
- Plan for the year after launch, not just the launch
Development process
Definition, design, build, ship — then keep going
Nothing exotic. The value was in doing each stage properly and not skipping to code, which is the usual failure.
-
Definition
Workshops turning the concept into journeys and a ranked scope, with an explicit agreement on what the first release would not contain.
-
Design
Screens and flows for both platforms, reviewed as a prototype so the client could use it before it existed.
-
Build
Cross-platform delivery in short cycles, with something demonstrable at the end of each, so progress was visible rather than reported.
-
Release
Testing on real devices, store submission, and the first release — followed immediately by the fixes that only real users find.
-
Two years of improvement
Continuous development after launch, which is what turned a shipped app into a product the client would describe as great.
Technology stack
Sized to the product, not to an imagined future
Conventional, well-supported technology chosen so a small team could move fast and the client could maintain it afterwards.
Apps
- iOS app
- Android app
- Shared application logic
- Push notifications
Backend
- API
- Accounts and authentication
- Database
- File storage
Design
- Design system
- Interactive prototype
- Both-platform patterns
Delivery
- Short cycles
- Device testing
- Store release process
Quality assurance & deployment
Tested on real devices, in real conditions
Mobile apps fail in the hands of users, not on a developer's desk. Testing covered real devices, poor networks and interrupted sessions before anything went to the stores.
- Automated tests for the app logic and the API
- Testing on real iOS and Android devices across the agreed versions
- Offline, poor-network and interrupted-session scenarios
- Code review on every change
- Store guideline checks during the build, not before submission
Deployment
- 01ReleaseTesting on real devices, store submission, and the first release — followed immediately by the fixes that only real users find.
- 02Two years of improvementContinuous development after launch, which is what turned a shipped app into a product the client would describe as great.
- 03Beta and store releaseA beta group used the app first; store submission followed, with a phased release.
- 04Monitoring and warrantyCrash and performance monitoring from launch, and six months of free bug fixing.
Business impact
What changed for the client
Three things that follow from doing the unglamorous stages properly.
-
A product that exists
Two app stores, real users, and a release process that made the next version routine.
-
Decisions made once
A ranked scope with written exclusions meant the same arguments did not recur every month.
-
Improvement after launch
Two years of continuous work is what turned a shipped app into one the client calls great.
Final deliverables
In the client's words: great, instead of just an idea
The client has a shipped mobile product on both stores, built over two years of continuous work rather than handed over at launch.
Their published review puts it better than we would: because of our expertise, their app became great instead of being just an idea. We did not write that sentence, and we cannot edit it.
- Concept turned into a defined, shipped product
- iOS and Android released and maintained
- Two years of continuous development, not a handover
- 5.0 rating in a verified Clutch review
Handed over to the client
- 01iOS and Android appsPublished in the client's store accounts
- 02Source codeIn a repository the client can access
- 03Backend and adminDeployed and documented
- 04Release processBuild, signing and store submission
- 05Six-month warrantyFree bug fixing after delivery
Success metrics
What it runs at today
The product as delivered and maintained.
-
2
Native platforms
iOS and Android, kept in step from shared logic
-
1
Team throughout
The same people from definition to two years past launch
-
5.0
Client rating
Rated by the client in a verified review published on Clutch
-
4
Stages before a line of code
Journeys, ranked scope, design, prototype
How success is measured
How success is measured
| Measure | Outcome | How it is measured |
|---|---|---|
| Faster feature delivery after launch | 2x | Measured across releases in the year following launch |
| Of store submissions passed first time | 100% | Across App Store and Google Play submissions |
| Of continuous improvement after launch | 2 yrs | Over the engagement of 2 years 1 month |
Client review
What the client said about the work
Published on Clutch, where the client is verified and we cannot edit or remove what they write.
-
Mobile App Development
Mobile App Development for a Software Company
Because of their expertise, our app became great instead of being just an idea.
Robin Jansson CTO, Necito Software Jan 2021 – Feb 2023 Verified review on Clutch (Robin Jansson, opens in a new tab)
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate