Software products built for how your business works.

• Choose a web application when users need accounts, state and permissions.

  People sign in, see only their own or their role data, and change records other people depend on. The data model and the permission model are then where the build starts.

• Choose SaaS when one codebase has to serve many organizations.

  You are selling access rather than delivering a project. Tenant isolation, plan entitlements, self-service onboarding and subscription billing become core work rather than extras.

• Choose a website when nobody needs to sign in.

  If no data has to persist between visits and every visitor can see the same page, an application is capability you will pay for and never use. Web design and development is the right category.

• Choose integrations and automation when the systems already exist.

  Where the problem is that three tools do not talk to each other, connecting them is cheaper than replacing them with something new that you then have to maintain.

One step at a time, and only when a process forces it. The trigger is usually a spreadsheet several people edit at once, a tool that nearly fits, or customers asking to use something built internally. Each step adds accounts, then tenancy, then billing — and each has to be justified on its own.

The reason to take the steps in order is cost. Adding accounts to a website is a contained piece of work; adding tenancy to an application that assumed one organization means revisiting every query in the system. Deciding early which step you are actually on prevents both overbuilding and the more expensive kind of retrofit.

• A website, while the job is publishing and winning inquiries.
• An application, once people sign in and records have to persist.
• A multi-tenant product, once other organizations pay to use it.
• A platform, once other systems need to build on it through an API.

Through APIs, webhooks and scheduled jobs. An API lets one system ask another for data or send it a change. A webhook lets a system announce that something happened. A scheduled job reconciles two systems on a timetable. Which shape applies decides how errors and delays are handled.

Most integration failures are not connection failures — they are unhandled ones. The other system is slow, returns something unexpected, rejects a duplicate, or is briefly unavailable. We specify that behavior rather than leave it to fail quietly, because a silent integration failure is discovered weeks later by a customer.

Where an application needs to be built on by other systems or by your own front ends, the API becomes a product in its own right: a documented contract, authentication, rate limiting, versioning, and a deprecation policy so a change does not break the work of somebody else without warning.

A dashboard shows you what is happening. An admin panel lets you change it. Administration tooling is where your own team manages users, records, settings, permissions and the things that go wrong — and it is what keeps routine operational changes from becoming developer requests.

It is the part of an application most often left until last and most often regretted. Without it, every correction to a record, every permission change and every support question becomes a task for whoever has database access. With it, the people running the business can run it.

• Managing users, roles and permissions without touching code.
• Finding, correcting and, where appropriate, restoring records.
• Seeing what a customer sees, so support is possible at all.
• Configuration and settings that change without a deployment.
• Audit trails, so who changed what and when is answerable.

By treating availability as data the system owns rather than a calendar people read. Slots are derived from rules — working hours, duration, buffers, capacity, notice periods — and a booking is only confirmed once it has been written, which is what prevents two people claiming one slot.

Most of the work in a booking system is not the calendar, it is the rules: who can book what, how far ahead, how late a cancellation is allowed, what happens to a rescheduled appointment, which resources are shared between services. Those rules are the actual requirement, and they are gathered before any interface is designed.

A plan defines what a member can access. The application checks that entitlement on every request, and billing events from the payment provider keep it current — so an upgrade applies immediately, and a failed payment changes access according to rules you set rather than because somebody noticed.

The failure to design out is billing and access disagreeing: a member paying for something the application does not grant, or retaining access they stopped paying for. Deriving entitlements from billing events rather than maintaining them by hand is what keeps the two in step. Which payment provider is used is your decision, and the integration is scoped against it.

A Progressive Web App is a website built so it behaves like an installed app: it can be added to a home screen, launch without browser furniture, tolerate a poor connection, and send web push notifications. It runs from one web codebase and needs no app store approval.

It suits products whose users return regularly on a phone and where an app store listing adds cost without adding reach. What it is not is a native application: device capabilities are narrower, and iOS support for some features lags Android.

Native iOS and Android development is a separate capability, and we will tell you plainly whether it is in scope rather than implying it. A Progressive Web App is what we build, and for a great many products it is the honest answer rather than the compromise.

One complete path through the process, used by real people. Not a fraction of every feature — a first release that covers one workflow end to end can be used, and use produces information no specification contains. Everything else is sequenced from what that release teaches.

The alternative is a long build against a specification written before anyone had used anything, which is how projects arrive late and wrong at the same time. Cutting the scope into releases that each stand alone also means the project has value before it has finished, which changes the risk profile entirely.

Deliberately and on a schedule. Dependencies receive security updates, browsers change, third-party interfaces get versioned, and usage patterns shift. An application is a running system rather than a delivered artifact, so who is doing that work and how often is agreed rather than assumed.

At handover you receive the repository, the data model, the environment configuration, the deployment path and the third-party account list — everything another developer needs to take it over. Where you would rather not, maintenance and support is an explicit arrangement under hosting, maintenance and support, not a dependency created by the way the project was delivered.

Many companies arrive here having already built the first of these and discovered its limits. The progression is not inevitable and each step should be justified on its own, but knowing which step you are on makes the next decision much cheaper.

• TypeScript end to end, so the shape of the data is enforced across the interface, the server and the database access layer.
• A relational data model by default, because most business processes are relationships and the database is the cheapest place to enforce them.
• Authorization checked on the server for every request; hiding an interface element is presentation, not a permission.
• Designed with appropriate security practices — hashed credentials, server-side sessions, optional two-factor authentication, parameterized queries, secrets in environment configuration.
• Releases sliced so the first useful version reaches real users early, instead of everything arriving at once at the end.
• Public marketing, pricing and documentation routes statically generated and indexable, with authenticated routes excluded from the index.
• Staging and production environments, a documented release process, and a rollback route rehearsed rather than assumed.