Custom builds
Full-stack web apps for small businesses: when you need one, and what it involves
A brochure website shows information. A full-stack app stores and changes information — bookings, quotes, orders, records. Here is how to tell which you need.
Website or web app?
If your site only needs to explain what you do and let people contact you, you need a website — pages, a form, a WhatsApp button. You need a web application when the site has to remember things and act on them: available time slots, a customer's previous orders, a quote that changes with options, staff who log in to update records.
Typical small-business examples:
- Appointment or site-visit booking that blocks taken slots
- Instant quotes from a few inputs (area, rooms, service level)
- A simple CRM to track enquiries across a small team
- A client portal to share documents or project status
- Order or reservation management for a restaurant or shop
Check for an existing tool first
Many of these needs are already solved by booking, invoicing or CRM software. If an existing tool fits your process, it is usually cheaper and faster to adopt it and link it from your website. A custom build makes sense when your process is genuinely specific, when you need several tools to work together, or when per-user subscription costs outgrow a one-time build.
The parts of a full-stack app
| Layer | What it does | Small-business example |
|---|---|---|
| Frontend | The screens people use, in the browser | Pick a date, enter details, see confirmation |
| Backend / API | Rules that must not be bypassed | "Don't allow two bookings in one slot" |
| Database | Where records are stored | Customers, appointments, staff |
| Authentication | Who is allowed to do what | Customers book; staff can reschedule; owner sees reports |
| Hosting & deployment | Where it runs and how updates ship | Serverless hosting, automatic backups, a test copy |
| Notifications | Telling people something happened | Email or WhatsApp confirmation, staff alert |
Worked example: appointment booking
- Map the flow first: choose service → choose date and slot → enter name and phone → confirm → both sides notified → staff can reschedule or cancel.
- Define the records: Service (name, duration), Slot (date, time, capacity), Booking (customer, slot, status), Staff (name, role).
- Write the rules: a slot can't be over-booked; cancellations free the slot; bookings close a set time before the slot.
- Decide permissions: what customers, staff and the owner can each see and change.
- Plan the failure cases: slot taken while the customer was typing, duplicate submissions, network errors — each needs a clear message, not a blank screen.
Written down, this fits on one page and makes quotes comparable. You can try a working concept of this flow in our booking demo (a demo we built, not a client project).
What drives cost
- Number of user roles and permission rules
- Number of screens and the states each can be in
- Integrations: payments, calendars, WhatsApp/email, accounting
- Importing existing data from spreadsheets or old systems
- Reporting and exports
The cheapest reliable build is usually the smallest version that solves the main problem, launched, then extended once people use it.
Security and reliability basics to insist on
- Validation on the server, not only in the browser
- Each role can access only what it needs
- Passwords never stored in plain text; sessions that expire
- Regular backups, and a test that restoring them works
- Error logs someone actually looks at
- Collect only the personal data you need, and say how you use it
After launch
An app is never "finished" in the way a brochure site is. Budget a little time for fixes, small improvements and keeping dependencies up to date, and make sure you own the code, the hosting account and the data. Ask how you would export your data if you ever switched provider.
We scope custom builds after a short conversation and suggest the simplest version that works — often a configured existing tool rather than new code. Tell us what you need.