Test your app idea before you build it.

Some jobs are better done in an app: booking, ordering, loyalty and community for your customers, or internal tools that replace your team's spreadsheets and paper forms. We design and build them for small businesses and founders, starting with a clickable prototype that real people try on their phones, so you see how they use it before the full build begins.

Get a free audit →What's included

Service: Mobile & web apps
Timeline: Longer than a website, with dates set for prototype, build and store review
Pricing: Fixed quote after a free audit
Built with: Figma, Replit, Bolt.new

Product design
Clickable prototypes
iOS & Android apps
Web apps
Internal tools
Admin dashboards
App Store launch

Sounds familiar?

Signs it's time.

Customers keep asking if you have an app
Bookings and orders arrive by text and phone
Your loyalty program is a paper punch card
Staff juggle three spreadsheets to finish one job
A marketplace takes a cut of every order
Your app idea hasn't been tested with users

When an app is worth it for a small business

An app asks more of your customers than a website does. They have to find it, download it, make room for it on their phone and choose to open it again next week. For a small business, that only makes sense when the app does something a website can’t do as well: reordering the usual in two taps, a loyalty card that’s always in their pocket, a class they can book straight from a reminder, a library they can listen to on the commute.

Internal tools follow the same test. If your team re-types the same order into three places, or a manager spends Friday afternoon reconciling a spreadsheet, a small custom tool can give those hours back and cut the mistakes that come with copying things by hand.

Sometimes the honest answer is that you don’t need an app yet. A faster website with online booking, or a well-chosen off-the-shelf tool, may solve the problem for much less. We’ll tell you that in the free audit, which costs you nothing.

Why we start with a prototype you can hold

Most app budgets aren’t lost to bad code. They’re lost to building the wrong thing well: features nobody uses, sign-up screens that scare people off, flows that made sense in a meeting but not on a phone held in one hand. A prototype, a clickable version of the app that looks real but has little or no code behind it, lets you find those problems while they’re cheap to fix.

We design the main journeys, put the prototype on a phone and hand it to real customers or staff. We watch where their thumbs hesitate, revise and test again. Our founder used the same approach on Facebook’s data center onboarding platform, an internal tool for new hires, where onboarding task time fell 34% and new-hire satisfaction rose nearly 20%. A small-business app is a smaller job, but the method holds.

AI tools make this phase faster. With Replit and Bolt.new we can stand up working prototypes with real data in them. That’s how we worked on Vulti, the poker-tech startup our founder started, which has a player app, an operator web app and a dealer device. People still make the decisions and review everything that ships.

Why apps get deleted, and how we design around it

Apps that get deleted usually aren’t broken. They ask too much too soon, or they forget about the person running the business. These are the mistakes we design around from the first sketch:

Sign-up before value. Let people browse the menu or schedule first, and ask for an account when they actually need one.
Too much in version one. A first release should do one or two jobs very well. The rest can wait for what real use tells you.
No admin side. If changing a price or a class time means emailing a developer, the app goes stale within months.
Undesigned moments. Empty lists, lost connections and failed payments need real screens, not error codes.
Notifications as a megaphone. Alerts should be useful, like “your order is ready”, or people switch them off and often delete the app.
Built for the newest phone only. We test on the older and smaller devices your customers actually carry.

A good app is quick, remembers people and is easy for your team to keep current. That last part decides whether it’s still useful a year after launch.

Launching alongside your website

An app doesn’t replace your website. Most people meet you through search, maps or social media first, and your site is where they decide whether to download. We make sure the website, the app store listing and the app itself look and sound like the same business, and that each one points to the next. For Best of Spurgeon, the website redesign and a web and mobile app were designed together to connect a large library of sermons and writings with an audio library and a meditation tool.

Launch is a plan, not a date. A download link on your site, a QR code at the counter and a note to your email list do more than a store listing alone. If you want help getting the word out, our campaigns and ads work picks up from there.

After launch, an app needs looking after like any software: yearly phone updates, small fixes and new features based on what customers actually use. You can keep us on month to month for that work or hand everything to your own developer, because you own the code, the accounts and the data either way. To find out whether an app is the right move for your business, book a free audit.

Who it's for

Businesses with regulars

Cafés, gyms, salons and shops where the same people come back every week. A loyalty, booking or ordering app gives them a faster way to reorder, book or earn rewards, and gives you a direct line to them instead of going through a third-party marketplace.

Founders with an app idea

You have a concept and need to know whether people will use it before you raise money or spend savings on development. A tested prototype is something you can show early users, partners and investors.

Teams running on spreadsheets

Your staff track jobs, schedules, stock or orders across spreadsheets, group texts and paper forms. A simple internal tool puts it all in one place, on the phones and laptops they already carry.

Communities and content libraries

You run a membership, a congregation, a class or an audience, or you have a large library of content like sermons, lessons, recipes or audio that is hard to browse on a website. An app makes it searchable, listenable and easy to come back to.

What's included

Everything below is part of the work — not an upsell waiting at the end.

Research with customers and staff

We sit with your customers or staff and watch how they book, order or work today. That decides what version one does and, just as important, what it leaves out.

A clickable prototype

A realistic, tappable version of the main screens that runs on a phone but has little or no code behind it. We build it in Figma (the design tool we work in), or with AI prototyping tools like Replit and Bolt.new when it helps to have real data behind the screens.

Prototype testing sessions

We hand the prototype to a handful of real users, note where they hesitate or get lost, and revise before any production code is written. Fixing a confusing screen at this stage is quick; fixing it after launch means a new release and another app store review.

Full interface design

Every screen designed for small and large screens, including the moments most apps forget: empty lists, loading, lost connection, failed payment. You also get a small design system (shared colors, type and buttons) so new screens match the old ones as the app grows.

iOS, Android or web build

For phone apps we usually write one shared codebase that runs on both iPhone and Android, known as cross-platform, using React Native. If your customers don't need anything installed, we build a web app that runs in the browser instead. We recommend whichever fits how people will actually use it.

Backend and admin dashboard

The backend is the server and database that store accounts, bookings, orders and content. We pair it with a simple admin dashboard so your team can change menus, prices, schedules and users without calling a developer.

Payments and integrations

Payments through Stripe for orders, bookings and deposits; if you sell subscriptions or digital content inside the app, we plan around Apple's and Google's own payment rules. We also connect the booking system, point of sale, calendar or email list you already use, wherever it offers an API (a documented way for one piece of software to talk to another). We check each connection during the audit, before you sign off on the quote.

App Store and Google Play launch

We prepare store screenshots, descriptions and privacy details, submit the app to Apple and Google, and work through any reviewer feedback. Web apps go live on your own domain.

How it works

Longer than a website, with dates set for prototype, build and store review. You'll always know what's happening this week and what's next.

01Days 1-3
Free audit
We look at your idea and your current setup: your website, your booking or ordering tools, and how customers reach you today. You get an honest answer on whether an app is the right move or whether a better website would do the job, and if an app makes sense, a fixed-price quote and a dated plan.
02Usually 2-3 weeks
Prototype and test
We map the key journeys, design the main screens and build a clickable prototype. You and a handful of real users try it on a phone, and we revise until the core flow is clear and nobody gets stuck.
03Dated in your plan
Full design and build
We finish the design for every screen and build the app, backend and admin dashboard in short cycles. You test working versions on your own phone along the way, through TestFlight (Apple's tool for sharing pre-release apps) and Google Play's internal testing.
04Final 1-2 weeks
Launch
We test on real devices, including older and smaller phones, prepare the store listings and submit to the App Store and Google Play. Once the app is approved, we help you announce it on your website, in store and to your email list.
05Ongoing
Support and updates
Apple and Google release a major phone software update every year, and apps need small fixes to keep working. We can stay on month to month for updates and new features, or hand everything to your own developer.

How pricing works

Your app gets a fixed price for our work after the free audit, agreed before any design or code starts. The biggest cost drivers are how many distinct screens and user types it has (a customer app plus a staff app is really two products), whether you need iPhone, Android and web, how many outside systems it connects to, and whether people log in and pay inside it. If you'd rather start smaller, we can quote the prototype on its own, then quote the full build once real people have tested it, so that price is based on screens people have actually used. Running costs such as store fees and hosting are billed to you by the providers and listed in your plan.

Get a fixed quote →

What you have at the end

Your app live in the App Store, Google Play or on your domain, under your accounts
Full source code in a code repository you own
Figma design files and the tested prototype
Admin dashboard logins for your team
Hosting, database and payment accounts in your name
A recorded walkthrough of how to manage the app day to day
Technical notes so any developer can pick up where we left off

Tools & platforms

Figma
Replit
Bolt.new
React Native & Expo
Next.js
Supabase
Firebase
Stripe
TestFlight
App Store Connect & Google Play Console

Questions about mobile & web apps

Something else? Ask us directly.

Do I need a phone app, or will a web app do?

Often a web app is enough: it works in any browser, there's nothing to download, and updates go live instantly. A phone app makes sense when you need things a browser handles poorly, like dependable push notifications (the alerts that appear on a lock screen), offline use or background location, or when customers will open it every week from their home screen. We make that call with you during the free audit.

Will my customers actually download it?

Only if it saves them time or gets them something they want, like reordering in two taps, rewards or booking without a phone call. That's why we test the prototype with real customers before building. We also plan how people will hear about it: your website, signs and QR codes at the counter, your email list and your receipts.

Whose name is the app published under?

Yours. The app is published under your own Apple Developer and Google Play Console accounts, which you register and pay for directly; Apple charges a yearly fee and Google a one-time fee. Publishing as a business also needs a D-U-N-S number (a free business ID that Apple and Google check), so we help you start that early. We're added as team members to do the submission work, and you can revoke our access whenever you like.

What does it cost to keep an app running?

Apple's yearly developer fee, hosting and a database that grow with your number of users, and any paid services the app calls on, such as payment processing or text-message reminders. These go on your own accounts, not our invoice. Your plan estimates each one at the usage you expect, so a busy month doesn't bring a surprise bill, and we design the app to keep them low.

What if Apple or Google turns the app down?

Store reviewers do send apps back, most often for missing privacy details, a sign-in they can't test, or an app that is little more than a website in a wrapper. We plan for those rules from the prototype stage and give reviewers a demo account, and if they still ask for changes, we make them and resubmit as part of the launch work. The final decision belongs to Apple and Google, so we build review time into your dated plan.

What happens when Apple or Google release an update?

Both release a major update every year, and apps sometimes need small fixes to keep working well and stay in the stores. We can handle that month to month, or document everything so your own developer can. Either way, you own the code and the accounts.