Mobile Apps
An app that works on the train, not only on office wifi.
What usually goes wrong
Phones punish assumptions that a website forgives. The signal drops halfway through saving something. A customer is two versions behind and will never update. A rejected release costs a week of waiting. A fault you released is live until Apple approves the fix. Teams who treat an app as a website in a smaller window find all of this out afterwards, from their star ratings.
What you end up with
- A clear answer to what happens with no signal, instead of a spinning circle
- Older versions that keep working for the customers who never update
- Releases that anyone on your team can publish, not just one person on one laptop
- Crash reports that point at the real cause
Inside mobile work
One app, both phones
Built once and released to both iPhone and Android, which keeps the cost and the ongoing work far lower than building the same app twice.
Working without a signal
What the app does on a train or in a lift, and what happens to anything saved while offline. Decided at the start, because it cannot be added neatly afterwards.
Keeping older versions working
A meaningful number of your customers will not update for months. The app keeps working for them while you keep releasing for everyone else.
Notifications and links
Push notifications handled properly on both phones, including when someone refuses permission, and links that open the right screen even from a cold start.
Releasing
Test versions your team can install, releases rolled out gradually so a fault reaches few people, and small fixes that can go out without waiting for approval.
Getting through the app stores
Store listings, screenshots, privacy declarations and the review process. We have read the rules so you do not have to, and we budget time for the rejection that sometimes comes.
What you get
- The app published under your own Apple and Google accounts, never ours
- Every key and certificate handed over securely
- A release process written down so anyone on your team can run it
- Crash reports that point at the real cause
- The store listing material both companies require
What is not included
Saying this plainly saves everyone a call.
- Games or heavy three dimensional graphics
- Rebuilding an existing app separately for each phone
- App store advertising and paid installs
- Software for physical devices and hardware
How this runs
- 01
Answer four questions
Which phones, how old a phone we support, what has to work without a signal, and which phone features you genuinely need. These four answers decide most of the cost.
- 02
Build the foundation
Moving between screens, saving information on the phone, and how the app talks to your system. The offline rule is settled now, not later.
- 03
Test on real phones
A test version every week on actual devices. Simulators on a developer's computer hide slowness and hide every permission prompt.
- 04
Prepare the release
Store listings, screenshots, privacy declarations and submission, with time set aside for a rejection.
- 05
After launch
Watch the crash reports, release gradually, and ship the first fix. There is always a first fix.
How this is usually arranged
We do not publish rates, because a number without a clear scope would mislead you. You get a real, fixed figure in writing after one conversation.
Fixed price project
A defined result, a fixed price and a delivery date, all agreed before work starts. If you want something added later, it is priced separately rather than absorbed quietly or argued about at the end.
Best for
A well understood piece of work: a website, an app, a check of existing software.
Dedicated team
One or more people working only on your product for an agreed period, planning with you week by week. In practice it is your software team, without the hiring.
Best for
Ongoing product work where the plan will change as you learn from customers.
Monthly support
A set amount of our time each month for looking after your software, making small changes and improving things gradually. It rolls on monthly, can be stopped with thirty days' notice, and always ends with a handover document.
Best for
Software that is live and needs to stay safe, up to date and working.
What people ask about this
We build one app that runs on both, and use the phone's own features directly where something genuinely needs it. For most businesses that is the right trade, because it costs far less to build and much less to keep updated. If your app needs the very last drop of performance, such as a game or heavy graphics, we will tell you honestly that we are not the right studio.
You do, once it is paid for, including everything produced along the way. It lives in your accounts from the first day, not ours. Hosting, your web address, app store listings and any other service are all set up in your name. Nothing about leaving us is made difficult on purpose.
A website or a focused web application is usually six to twelve weeks. A first release of an online product is three to six months. A mobile app is two to four months to the first store release. Checking existing software takes three to five days. Those are honest starting ranges. You get a real date in the written plan once we understand the job, and we would rather quote longer and be right.
You get written instructions and a walkthrough with whoever will look after it. Then either your own team runs it, or we keep looking after it for a monthly fee. Both are fine, and we will tell you which one we think suits you. What we will not do is disappear on launch day and leave you with something nobody understands.
You might also need
- 01Websites and Web AppsCompany websites, online shops, customer portals and internal tools, built so they stay fast and stay easy to change.
- 02Online ProductsSubscription products and platforms, including the accounts, payments, permissions and behind the scenes work a product needs once paying customers arrive.
Talk to us about this
Thirty minutes, nothing to prepare. We will tell you honestly whether we are the right studio for it.