Web application development
Custom web applications, shaped around the way your business works.
Custom web applications for processes that spreadsheets and disconnected tools can no longer support. Bring workflows, permissions and business data into one usable product.
Illustration: a spreadsheet fragment, with two cells that disagree, reflows into an application record with a status, an approver, a three-step numbered status rail and a history list.
Build around the work, not around a feature list.
Custom software becomes useful when it reflects the decisions people make during a real task. We begin with the current process: who starts it, who approves it, what information changes and what happens when a step fails. That often reveals a smaller first release than the original feature list suggests. Before recommending a build, we also examine whether an existing product can cover the need with less cost and operational responsibility.
Who starts it
The person, form or system event that begins the task, and what it must contain.
Who approves it
The decisions that stay with a person, and who signs them off.
What information changes
The records the task creates or updates, and the system that owns each one.
What happens when a step fails
The route a failed or incomplete step takes back to someone who can resolve it.
Switch roles and see one application change.
Explore an example supplier portal as a customer administrator, a customer user and a member of staff. Each customer sees only the records their organization has approved for that contact. Access revocation takes effect even if a session remains open. The portal shows that data is delayed instead of presenting a clean but misleading screen. The portal returns a reference and distinguishes receipt from assignment and resolution.
View as
Try a situation
Customer admin view
- Quotation Q-2041Approved document
- Packaging changeProject decision
- Order 5521Order status from the CRMUpdated 09:14Delayed, last updated 09:14
- Delivery addressesAccount record from the CRMUpdated 09:14Delayed, last updated 09:14
Contacts on the account
- Customer admin (You)Active
- Customer userActiveAccess revoked
Shows the records shared with the account, and its contacts.
Customer user view
- Quotation Q-2041Approved document
- Packaging changeProject decision
- Order 5521Order status from the CRMUpdated 09:14Delayed, last updated 09:14
- Delivery addressesAccount record from the CRMUpdated 09:14Delayed, last updated 09:14
Shows only the records shared with this contact.
Staff view
- Quotation Q-2041Approved document
- Packaging changeProject decision
- Order 5521Order status from the CRMUpdated 09:14Delayed, last updated 09:14
- Delivery addressesAccount record from the CRMUpdated 09:14Delayed, last updated 09:14
- Draft invoice INV-0318Internal until approvedStaff only
- Account noteStaff noteStaff only
Contacts on the account
- Customer adminActive
- Customer userActiveAccess revoked
Shows the shared records and the internal items marked staff only.
Access revoked
Customer user
Session ended
Access to account A-1047 was revoked. Ask the account administrator if this looks wrong.
Customer admin and Staff
The customer user’s access is revoked. Their open session has ended.
CRM unavailable
The CRM is unavailable.
Account details were last updated at 09:14 and may be out of date.
Request REQ-1048
Damaged carton in the last delivery
- 1ReceivedReference REQ-1048 returned
- 2AssignedWith the support desk
- 3Resolved
Replacement confirmed
Staff only
Internal: the order history for 5521 is attached for the support desk.
Where custom development is worth the responsibility.
Custom software earns its cost when the process matters enough to maintain and standard software cannot represent it.
Build it when
Your rules, users or integrations are difficult to represent in standard software, and the process is important enough to maintain.
- The rules are specific to how your business works
- Several roles act on the same records
- Integrations carry business decisions, not only data
Look elsewhere when
The workflow is short-lived, or the problem is already solved well by an existing platform.
- The workflow is short-lived
- An existing platform already solves the problem well
- An existing product covers the need with less cost and operational responsibility
We discuss hosting, third-party licenses, data migration, access ownership and support before committing to a technology stack. Those choices affect total cost and delivery risk.
From a first useful release to a maintainable product.
The exact scope is agreed in a proposal. A typical discovery and delivery discussion covers these connected areas.
| Area | What we define | Why it matters |
|---|---|---|
| Product definition | User roles, task flows, acceptance criteria and a prioritized release boundary | The first release makes an important task easier to complete, not merely longer |
| Application and data | Interfaces, server-side permissions, business rules and data relationships, designed together | The states between success and failure matter as much as the main path |
| Integration | Authentication, duplicate handling, retries and a way to see failures for each agreed API connection | A failed exchange is visible before it becomes a wrong record |
| Release and operation | Environments, tests, deployment, monitoring and who can make changes after handover | A connected application needs an operating model, not only source code |
Decisions that cannot be made yet remain visible as dependencies.
One application, designed layer by layer.
We identify which records the application owns and which belong to another system, then design each layer together with the next.
Interface
Task screens in your customers’ language, with the states between success and failure designed alongside the main path.
Permissions
Checked on the server for every record and action, not only hidden in a menu.
Business rules
Approvals, validations and the exceptions a real task meets, recorded with the reason each rule exists.
Data
The records the application owns, their relationships and their history.
Integrations
Agreed API connections with authentication, duplicate handling, retries and visible failures.
Four phases, with decisions kept close to the work.
Each phase ends with something the people who will use the product can review.
Define the first release
We turn the core workflow into user roles, task flows and acceptance criteria, and choose the smallest set of users and tasks that solves a real problem end to end.
Build in reviewable steps
Interfaces, permissions, rules and data are built together and demonstrated as working flows, not as screens alone.
Keep decisions close to the people doing the work
We review working flows with the people who will use and operate the product. A screen may look correct while an approval rule or exception still blocks the task. Regular demonstrations expose those gaps while they are cheap to change. We record decisions and test cases alongside the implementation, so a later team can understand why a rule exists rather than reverse-engineering it from code.
Plan ownership before launch
Your organization should know who controls the repository, provider accounts, environments, backups and application data. We agree what documentation, training and support are included and how defects or change requests are handled after release. New requirements, historical-data cleanup and provider charges are scoped separately; they should not appear as surprises during handover.
When a website has become an application.
Many projects begin in Joomla or WordPress and grow into account areas, approval workflows, booking tools or connected customer services. At that point, moving to a custom stack is a product decision as well as a technical one. We separate publishing from business rules and identify which part needs to change first.
Python and Django
Consider Django for data-heavy workflows and a structured backend. Design the data relationships, permissions and operator interface together; an administrative screen is not a substitute for a customer-facing product.
View Django developmentPHP and Laravel
Laravel can suit teams that want a custom application while keeping PHP expertise. Existing Joomla or WordPress plugins do not become Laravel features automatically: each important behavior needs a replacement or a deliberate redesign.
View Laravel developmentReact, Next.js and Astro
React and Next.js can support interactive product interfaces. Astro is an option for content-led public pages with focused interactive elements. Choose the rendering and content workflow per journey, rather than forcing every page into the same frontend pattern.
View React & Next.js development
Agree what must survive the change
- Content and media
- Customer access and permissions
- Transaction history, where in scope
- Integrations
- Important search destinations
- The URL map, kept with the release
Rehearse a representative export and import on an isolated copy. Agree how records created during cutover will be reconciled and what happens if the release must be reversed.
A platform change does not require changing every public address. Preserve useful URLs where possible, and document permanent redirects only where a page genuinely moves.
Some of the teams we have worked with.
Across talent, fitness, mobility, payments and local commerce.Questions about custom applications.
How do we decide what belongs in the first release?
Choose the smallest set of users and tasks that solves a real problem end to end. Include the permissions and failure paths needed to make those tasks safe. We can place lower-priority ideas in a visible later-phase list rather than treating every idea as a launch requirement.
Can the application use our current CRM or other systems?
We first identify the system that owns each record and inspect its available API, access model and limits. Integration is then scoped around specific data exchanges and failure recovery. We do not assume that an existing system permits every read or write the proposed workflow needs.
Who maintains the application after delivery?
That is agreed before implementation. We can define an operational handover for your team or scope continuing support. Either way, provider ownership, deployments, monitoring, backups and the process for approving changes need clear owners.
Can an existing site be moved in phases?
Often, yes. A new public frontend or a separate workflow can be introduced before replacing the rest. Shared authentication, data ownership and deployment boundaries must be designed explicitly so a phased project does not create two conflicting systems.
Continue exploring
Continue exploring
Customer portal development
Secure portals where customers check invoices, reorder and raise requests, for distributors, manufacturers and service firms. First releases typically cost $12,000–$30,000 and take 6–10 weeks.
View Customer portal developmentCRM & API integrations
CRM and API integrations that move the right information between teams and tools. Build around clear ownership, permissions and a recoverable path when something fails.
View CRM & API integrationsWebsites & platforms
From a clear business website to a connected customer portal, we design and develop web experiences around the people who use and manage them.
View Websites & platforms
Bring the process your spreadsheet can no longer hold.
Describe who starts it, who approves it and where it fails. We can outline a first release that makes one important task easier to complete.
Technology names and marks belong to their owners.