Web applications for the process your business actually runs

What web application development actually means

Web application development means building software that runs in a browser and does work: it holds state, enforces rules about who may change what, and produces an outcome. A booking system, a client portal, a quoting tool and an internal dashboard are all web applications, and none of them are websites with extra pages.

Web application development and website application development describe the same work; the second is simply how more people search for it. Either way the deliverable is software, and the cost is driven by rules and states rather than by page count.

The distinction from an ordinary website is not pedantry, it is what drives the cost. A website can be wrong in ways that embarrass you. An application can be wrong in ways that charge the wrong person, double-book a slot, or show one customer another customer’s record. That is why applications need specification, roles, constraints and an audit trail, and why they cannot be responsibly quoted from a paragraph.

Who this is for

• Businesses running a core process on a shared spreadsheet that nobody is allowed to sort
• Companies that need customers or staff to log in and see only their own data
• Operations with a workflow that has stages, approvals and handoffs
• Businesses paying per-seat for SaaS that does eighty per cent of what they need, badly
• Anyone whose process depends on a person remembering to do something at the right time

Who it is not for

Saying this out loud costs me some enquiries and saves both of us the ones that would have gone wrong. If you are on this list, I will tell you in the first reply rather than after a deposit.

• Projects that are genuinely a content website with a form. That is cheaper and faster as a website
• Businesses wanting a mobile app for an app store — that is a different platform and a different discipline
• Real-time collaborative editing or heavy live data, which needs an architecture this stack is not the right choice for
• Organisations that have not agreed internally what the process is. The application will expose that, expensively

The problems it solves

A spreadsheet as the system of record

Data moves into a relational schema where the database itself refuses to accept contradictions.

No idea who changed what

An audit trail on anything touching money or status, recorded automatically rather than by discipline.

Everyone can see everything

Role-based access checked on every route, server-side, rather than by hiding buttons in the interface.

The process only works because one person remembers

States and transitions are enforced by the system, so the step cannot be skipped.

Double bookings and race conditions

Handled at the database level with constraints and transactions, not with a check the application performs and hopes.

Reporting means exporting and pivoting by hand

The reports that justified the build are built into it, which is often the entire business case.

What you get

• Specification covering user roles, permissions and every state a record can legitimately be in
• Relational schema designed first, with constraints enforced in the database rather than hoped for in the code
• Authentication with hashed credentials, session handling and role-based access control
• The application itself: forms, lists, filters, actions and the reporting that justified building it
• Transactional email sent through your own authenticated domain
• Audit trail on anything that changes money or status
• Deployment, environment configuration and a backup procedure verified by an actual restore
• 30 days of snag fixes after go-live

What is included in the starting price

Everything below is in the $200 figure. Nothing here is quoted as an extra once the build is underway, which is the point of publishing it.

• Specification covering roles, permissions, states and transitions
• Relational schema with constraints enforced in the database
• Authentication with properly hashed credentials and session handling
• Role-based access control checked server-side on every route
• The application: forms, lists, filters, actions and reporting
• Audit trail on records that change money or status
• Transactional email through your own authenticated domain
• Deployment, environment configuration, and backups verified by an actual restore
• 30 days of snag fixes after go-live

What costs extra, and why

A quote that omits these is not cheaper — it is less honest. Each one is real work that someone has to do, and pretending otherwise is how a fixed price becomes a negotiation in week two.

Third-party integrations

Accounting, payment, dispatch or CRM. Each is its own project with its own failure modes.

Data migration from the existing system

Usually the messiest part. Quoted once the real data has been seen rather than described.

User training and documentation

A short walkthrough is included. Formal training materials for a large team are separate.

Ongoing feature development

Applications grow with the business. A retainer beats a series of small quotes.

Load testing

Worth it when concurrency is genuinely a risk, and worth skipping when eleven people use it.

How the work runs

1. Specify. Roles, states and rules written down. An application without a state diagram is a pile of forms that will contradict each other by week two.
2. Schema. The relational model, including what the database itself refuses to allow. Constraints in the schema outlive every developer who ever touches the code.
3. Build. Vertical slices — one complete workflow working end to end before the next one starts, on a staging URL you can use.
4. Harden. Prepared statements everywhere, server-side validation, access checks on every route, and error handling that logs rather than leaks.
5. Launch. Deployment, backups verified by restoring them, and handover documentation covering how to operate the thing.

Day by day

10 days from the day scope is signed off. Published as a schedule rather than a promise of speed — you should be able to tell on day three whether a build is on track.

The technology

Deliberately boring, and that is the feature. A stack another developer can pick up is worth more to you than one that impresses other developers.

Application

PHP 8 with a clear routing and controller structure, written rather than generated

Database

MySQL with foreign keys, unique constraints and transactions used properly

Authentication

Password hashing with a modern algorithm, secure session cookies, role checks server-side

Front end

Server-rendered HTML with Tailwind CSS, and Alpine.js for interaction that genuinely needs it

Hosting

Shared cPanel handles most business applications. A VPS where isolation or scheduling requires it

What it integrates with

• Stripe for payment collection, subscriptions and refunds
• Authenticated SMTP for transactional email that reaches inboxes
• Accounting exports in a format your bookkeeper will actually accept
• Any documented REST or JSON API
• Scheduled jobs via cron for reminders, imports and recurring tasks
• CSV import and export, because it remains how most businesses move data

What I need from you

Short list, and the first item matters most. Projects do not usually slip because the code was hard — they slip because a decision waited a week.

• A decision-maker who understands the process end to end, available during specification
• The real rules including exceptions, escalations and who is allowed to override what
• A list of roles and precisely what each one may see and do
• Sample data, including the records that broke the previous system
• Hosting, domain and third-party accounts in your name

Content and photography

Applications are specified rather than written, and the thing to prepare is not copy but rules. Write down every state a record can be in, and who may move it from each state to each other state. If two people in your business answer that differently, the application cannot resolve it for you and the build will stop there until you do.

Bring the exceptions deliberately. The order that was refunded after dispatch, the booking cancelled by someone other than the person who made it, the customer with two accounts. Those cases determine the schema, and discovering them in week two is how a ten-day project becomes a fifteen-day one.

Performance standards

Targets, not aspirations — measured before handover on a throttled mobile connection rather than on a fast laptop.

Accessibility standards

This site is built to the same standard it sells, and the accessibility statement lists what is conformant and what is not — which is the part most statements leave out.

Security practices

The SEO included in every build

Not an upsell. A site that launches unindexed is a shop with the shutters down, and the work below is cheap during a build and expensive afterwards because the fixes are structural.

Ownership and handover

You own everything: the domain registered to you, hosting in your account, code in a repository you control, and the payment provider account in your business name. Credentials are handed over as they are created rather than at the end.

A supplier who resists this is protecting recurring revenue rather than your interests. If you want the reasoning in full, including how to check your current site, there is a guide on it.

Aftercare and what happens after launch

Thirty days of snag fixes are included. A snag is something that does not work as scoped — not a new feature, and the difference is written down before launch rather than argued about after it.

You also get written handover documentation aimed at whoever maintains the site next, which may well not be me. That is deliberate: the test of a good handover is whether another developer could take over without calling me, and on my projects they can.

Ongoing maintenance

Optional, monthly, cancellable. Nothing here is required to keep what you paid for.

Payment terms

How this compares to the alternatives

Including the routes that do not involve me, because a comparison that only flatters the author is not a comparison.

What could go wrong, and how it is handled

The process is not actually agreed internally

Surfaces during specification. Better a difficult conversation on day one than a system nobody uses.

Existing data is worse than described

Migration is quoted after seeing real data. Estimating it from a description is how migrations overrun.

Scope grows once people see it working

Expected and healthy. It is re-quoted rather than absorbed, so the timeline stays honest.

Hosting cannot support scheduled jobs

Checked before quoting. Some shared hosts restrict cron, and it is far cheaper to know that first.