Business Applications

Internal tools, portals, and reporting systems shaped around how a business actually works, instead of bending the business around packaged software.

Most businesses reach a point where the spreadsheet stops working. Several people need it at once, nobody is sure which copy is current, and the one person who understands the formulas is on holiday.

The usual next step is packaged software that does eighty per cent of the job, followed by years of working around the other twenty. A custom application is the other option: built around the process you actually have, owned outright, and changeable when the process changes.

What you get

  • A relational schema designed for the data you actually hold, with constraints that prevent bad records
  • Role-based access control, so people see what their job requires and no more
  • Safe concurrent editing — two people working at once cannot silently overwrite each other
  • Audit trails on the records where knowing who changed what matters
  • Reports and exports your team can run without asking anyone
  • Versioned, forward-only database migrations so changes are repeatable
  • Documentation covering the schema, the deployment, and what to check when something misbehaves

How the work is done

Start from the real process

Not the process as documented — the process as performed, including the parts people do not mention because they assume everyone works that way. That is where the requirements that break a packaged system usually hide.

Get the data model right first

Application code is cheap to change. A schema with a hundred thousand rows in it is not. Time spent on the model before writing screens is the highest-value time in the project.

Ship in usable stages

One part of the system, working and in use, beats a complete system six months away. It also means the project can stop or change direction without wasting what has already been paid for.

Assume it outlives the enthusiasm

Plain SQL, plain PHP, and a schema someone else can read. No framework whose major version bump becomes your problem in three years.

What this does not cover

This is not a fit for problems a well-chosen off-the-shelf product already solves. Payroll, accounting and CRM have mature options, and building your own is rarely the right call. Where an existing product is close but does not connect to anything, the better answer is usually integration work rather than replacement.

Questions

Who owns the code?

You do. It is your system, on your hosting, and you can hand it to another developer at any point. That is the main practical argument for building rather than renting.

What database do you use?

MySQL or MariaDB by default, because it is what almost every business host already runs and it means no additional infrastructure. PostgreSQL where a project genuinely benefits from it.

Can it connect to software we already use?

Usually. If the other system has an API, a database, or even just a scheduled file export, there is normally a way in. See the automation and integrations page.

Related

Automation and API Integrations

Removing the manual step between two systems: scheduled imports and exports, API integrations, and reports that generate themselves.

Legacy System Modernization

Bringing an old but working system onto supported PHP and database versions without a rewrite and without losing behaviour people depend on.

Security and Hardening

Making a site survive the automated traffic every public site receives, and cleaning up properly when something has already got in.

Have a system that needs building or fixing?

Describe the problem and you will get a direct answer about whether it is worth doing, roughly what it involves, and what it would take.

Start a conversation