Discovery and architecture
Scope, user flows, technical architecture and a written product requirements document. The unglamorous phase where most of the money is either saved or lost.
Salt · Build
Apps your users trust and your team can maintain
Web and cross-platform mobile products, taken from architecture to the app stores and kept alive afterwards.
Most apps do not die at launch. They die three months later
The failure is rarely the launch build. It is the codebase nobody outside the original developer can read, the store rejection nobody planned for, the absence of analytics that makes every roadmap argument a matter of opinion, and the moment the freelancer stops answering.
We build assuming someone else will maintain it — including you. That changes the architecture, the documentation and what we hand over.
What we do
Product design
UX and UI built to Apple's Human Interface Guidelines and Material 3 so the app feels native on each platform, reviewed for accessibility rather than retrofitted for it, and delivered as a design system your team can extend.
Engineering
Web applications and cross-platform mobile in React Native or Flutter, with native work where the hardware demands it. Two-week sprints, a working build at the end of each one, and no phase where you cannot see the product.
QA and release
Automated and manual testing across the device matrix, then submission to the App Store and Google Play handled by us — including privacy manifests, data safety declarations and the review cycle.
Analytics, monitoring and support
Event tracking wired to the decisions you need to make, crash and performance monitoring, over-the-air updates, and an agreed support arrangement so the app has an owner on Monday morning.
What you get
- A shipped application, live on the stores or on your infrastructure
- Source code and CI/CD pipelines in your own accounts
- A design system in Figma, matched to the built components
- Technical documentation and a recorded handover
- Analytics, crash reporting and release tooling configured
- A maintenance and iteration plan
How the build runs
- 01
Discover
Users, flows, scope, architecture, and the one metric the first release has to move.
- 02
Accelerate
Design and engineering sprints, shipping to TestFlight and Play internal testing from early on.
- 03
Refine
QA across devices, performance, accessibility and store compliance ahead of submission.
- 04
Elevate
Release, watch the analytics, and iterate against what real users do rather than what the roadmap assumed.
Stack we work in
- Mobile
- React Native Flutter Swift Kotlin
- Web
- React Next.js Astro TypeScript
- Backend
- Node.js PostgreSQL Supabase REST / GraphQL
- Delivery
- CI/CD TestFlight Play Console Crash & performance monitoring
Numbers we move
- Time from kickoff to a build in real users' hands
- Crash-free session rate
- Activation — the share of installs that reach the core action
- Retention at day 7 and day 30
- Cost and time to ship each subsequent release
Frequently Asked Questions
Native or cross-platform?
Cross-platform for most products: one codebase, two stores, meaningfully lower cost to maintain. Native when the product depends on hardware, heavy graphics or platform features that cross-platform frameworks reach late. We decide in discovery, not by default.
Do you handle the App Store and Google Play submissions?
Yes, including privacy manifests, data safety forms and the review cycle. Store rejection is a scheduling risk, so we plan for it rather than discover it.
What happens if we want to take development in house later?
That is a normal outcome and we build for it. Code, pipelines and accounts are yours throughout, and the handover includes documentation and a working session with your team.
Tell us about your app
Describe what it needs to do and who it is for. If a smaller first release would get you the same answer sooner, we will say so.