LARAVEL · SYMFONY · NODE.JS · REACT · VUE

When the CMS is the wrong shape for the problem.

A lot of software starts life as a spreadsheet that got important. Then somebody tries to make a CMS do it, because a CMS was already there, and eighteen months later the site is carrying business logic it was never designed to hold and nobody wants to touch it.

We build the application properly when that is what the problem needs. Laravel, Symfony or Node on the back, React or Vue on the front, and a data model designed for the process rather than bent around one.

Discuss an application See what we have built
WHAT WE USUALLY BUILD
APPLICATIONS
  • Internal tools and admin systems
  • Client and partner portals
  • Dashboards and reporting
  • Booking, quoting and workflow tools
  • Marketplaces and directories
AND THE PLUMBING
  • REST and GraphQL APIs
  • CRM and ERP integrations
  • Payment provider integrations
  • Authentication and SSO
  • Scheduled jobs and queues
What we build

Five kinds of application, and what each is for.

These cover almost everything we are asked for. The common thread is a process that has outgrown whatever is currently holding it.

01

Internal tools

The spreadsheet that became load bearing. Quoting, scheduling, stock, approvals, onboarding. Built around how the team actually works instead of how a generic product assumes they do.

  • Role-based permissions and approval chains
  • Audit trails on anything that matters
  • Bulk operations and import routines
  • Exports that finance will accept
02

Client portals

An authenticated area where a customer sees their own orders, documents, reporting or account, so your team stops emailing PDFs.

  • Account and sub-account structures
  • Document access with permissions
  • Self-service that reduces support load
  • Notifications people do not switch off
03

APIs and integrations

Connecting systems that were never designed to talk to each other, in a way that survives one of them being unavailable.

  • REST and GraphQL service design
  • Queued jobs with retry and dead-letter handling
  • Failure surfaced rather than swallowed
  • Versioning so consumers do not break
04

Dashboards and reporting

Operational data turned into something a person can act on in under a minute, rather than a report nobody opens.

  • Aggregation designed for the query, not the schema
  • Scheduled and on-demand exports
  • Access control on sensitive figures
  • Performance that holds as data grows
05

Application rescue

Builds that stalled, overran, or lost the only person who understood them. Always begins with reading the code rather than promising a date.

  • Audit of code, data model and deployment
  • Honest continue-or-restart recommendation
  • Stabilise first, then improve
  • Documentation written as we go
06

The parts nobody quotes for

The work that decides whether an application is still usable in year three, and the first thing dropped when a quote is being squeezed.

  • Automated tests around business logic
  • Environments that match production
  • Error tracking and structured logging
  • Database migrations that are reversible
Honest fit

We turn down custom builds fairly often.

Build custom when

  • The process is genuinely specific to how you operate
  • Off-the-shelf would need heavy customisation anyway
  • Integration with internal systems is central
  • The data model is the product
  • You will own and fund this for years

Do not build custom when

  • An existing SaaS product covers 90% of it
  • The requirement is still changing weekly
  • Nobody internally will own it after launch
  • The budget covers the build but not the upkeep
  • It is really a reporting problem in disguise
Questions

What clients ask about custom builds.

How do we know whether we need a custom application or a CMS?
A rough test: if the value is in publishing and presenting content, a CMS is right. If the value is in a process, with states, permissions, calculations and things that must happen in order, a CMS will fight you. Most requirements have some of both, and the honest answer is often a CMS for the site and a small application beside it.
Which stack do you use and why?
Laravel or Symfony for most PHP work, Node.js where the workload suits it, with React or Vue on the front end. The reasoning is mundane: these are mature, well documented and widely known, so you can hire for them or hand the project to another team without a rewrite. We avoid picking something interesting over something maintainable.
Can you integrate with our existing systems?
That is usually most of the work. CRMs, ERPs, accounting systems, payment providers, internal databases and third-party APIs. The awkward part is rarely the connection itself, it is agreeing what happens when the other system is down, slow, or returns something unexpected, and building so those failures surface rather than fail silently.
Do you build mobile apps?
Not native iOS or Android. We build responsive web applications, and hybrid apps with Cordova or Ionic where a store presence is genuinely required. If you need a true native app we will say so rather than talk you into a compromise.
How do you handle authentication and security?
Framework-native authentication rather than anything homegrown, with role and permission models designed up front instead of added later. Single sign-on through SAML or OAuth where you already have an identity provider. Anything touching credentials or payments is written and reviewed by a person, never left to generated code.
What does the project actually look like week to week?
Two-week sprints with a demo of working software at the end of each. A staging environment from the first week so you are clicking through the real thing rather than reading a status report. You see it early enough that changing direction is still cheap.
Can you take over an application somebody else started?
Yes, and it starts with an audit rather than a promise. We read the code, the data model and the deployment setup, then tell you honestly whether continuing or restarting is cheaper. Sometimes the answer is unwelcome, and it is better heard before more money goes in.
Who owns the code?
You do, outright, on payment. It lives in your repository under your account, with the deployment pipeline and credentials handed over. Nothing depends on us continuing to be involved.
How do you price custom work?
Fixed price against a written scope once discovery is done, or a monthly rate for ongoing capacity where the requirement will keep evolving. Both are preceded by a free written technical assessment, because pricing a build nobody has scoped properly is guesswork dressed as a quote.
What happens after launch?
You get documentation aimed at a developer who has never met us, the pipeline with credentials, and a walkthrough. Most clients keep a small monthly retainer for changes and monitoring, but the handover is complete either way.
Get in touch

Describe the process that is eating people’s time.

A spreadsheet, a workflow diagram, or a description of what your team does by hand every week. Within one working day you get a reply from the engineer who would build it.

Before anything is signed, you get a written technical assessment: the real scope, where the risk sits, what we would build differently and why, and a fixed price against it. It costs nothing and it is yours to keep either way.

Reply within one working day, from an engineer Free written technical assessment Fixed scope and price before you commit
Request a technical assessment WhatsApp

Related

AI AI integration LLM features built into the platform you already run. WHITE LABEL White-label for agencies How we work under your brand, inside your repository and process. SUPPORT Support & maintenance Monthly retainers for live platforms, including ones we did not build.