MADTech / Mobile apps
Mobile app design & development.
What this covers
Flows before screens
We map what someone is actually trying to finish, end to end, before anything gets designed. Screens fall out of the flow rather than the other way around — which is also what stops the budget wandering.
Touch-first interface
Targets you can hit while walking, navigation that works one-handed, and feedback fast enough that nobody taps twice wondering if it registered.
State that survives real life
Signal drops, calls come in, phones die. The app remembers where you were and syncs when it can, instead of quietly losing your work.
Release and store handling
Builds, review submissions and the metadata that goes with them. The part everyone forgets to budget for.
Questions before you start
Should this be a mobile app or a responsive website?
Start with how people will use it. A website may be enough for information and occasional tasks. An app is worth considering when people return to the same task on their phone, in the field or on the move. We work through that choice before committing to an app build.
What happens when someone loses their connection?
We identify which tasks need to work without a connection, what information must be saved, and what should happen when the app reconnects. Those decisions belong in the scope because different tasks need different offline and sync behavior.
What should I send for an app quote?
Describe who the app is for and one task they should be able to complete from start to finish. Include the phones or other devices they use and any existing accounts, data or software it needs to work with. If this is a first release, separate the essential task from ideas for later.
A good fit when
- You have an idea for an app and want a real version of it, not a prototype
- The task genuinely belongs on a phone, not in a browser tab
- People will use it repeatedly, in the field or on the move
Probably not when
- A responsive website would do the same job for a fraction of the cost
- You want an app mainly because competitors have one
- You want to hire by the hour and direct the build yourself
I would rather say so up front than take work that will not land well.
How I work
Priced per project, never by the hour
Every project is different, so every price is worked out from your actual requirements rather than read off a list. You get a figure in writing before anything starts, and you are buying a finished thing rather than my time.
Custom code, not drag-and-drop
I do not build on page builders or theme editors. If you already run a platform that allows real custom code — GoHighLevel, for instance — I can build inside it. What I will not do is assemble something from blocks and call it bespoke.
Fast is possible, and it is priced as fast
Tight deadlines are often doable — a website in a few weeks is realistic. Compressing a schedule costs more, and how much depends on the size of the build. I will tell you what is achievable before you commit to a date.
Building only, not marketing
I design and build. I do not run ads, SEO or marketing campaigns, and I would rather say so than take money for something outside what I do well.
How it works
- 01
Send the messy version
A paragraph is enough. What it is, who it is for, and what is broken or missing today. I read it myself and reply — including an honest no if I am not the right fit.
- 02
Scope and a price range in writing
Before anything is built you get what is in scope, what is not, a range rather than a fantasy number, and a timeline. Nothing starts without that agreed.
- 03
Built in the open
You see it as it comes together, not at the end. Feedback lands while changing course is still cheap, which is the whole point of working this way.
- 04
Handed over properly
You get the code, the accounts in your name, and a walkthrough of how to run it. No hostage situations, no rented access to your own product.
Bring the messy version.
Tell me what you are trying to build and you get a straight answer on scope, cost and timeline — or an honest no.
Request a quote