Where this service fits
A custom web application is useful when the work depends on your own roles, records and business rules. A customer may need to submit a request, track its status and respond to a question. Your team may need a different workspace to review that request, update a record and handle an exception. We map both sides before deciding what the application should contain.
Development connects the interface to authentication, data and the integrations that make the workflow possible. We plan validation, search, permissions and activity states alongside the main screens. A first release should support a complete useful journey, including the administrative work behind it. Later features can be prioritised from a shared backlog as you learn how people use the product.
THE WORK IN PRACTICE
Applications built around a complete task.
HFS
HFS connects freelancers, companies and administrators through onboarding, shift allocation and payment tracking. Its web and mobile scope shows why the customer journey and the operational workspace need to be designed together.
Read the HFS case study
FloorPlanz Pro
FloorPlanz Pro combines room geometry, carpet planning, saved projects and PDF exports in a web application with PWA support and an iPad release. The original laptop and tablet views show a professional tool beyond a content website.
Read the FloorPlanz Pro case studyWhat the work can include
We agree the deliverables around your product and existing setup. A focused engagement can include the following work.
- User roles, journeys and an agreed first-release scope
- Responsive application screens and accessible interaction states
- Data models, APIs and scoped third-party connections
- Administration, testing and release preparation
Planning your project
Bring examples of the records people work with, the steps they follow and any systems that must remain connected. Account types, approval rules, imports and reporting needs affect the scope. We also discuss who maintains the application and which parts need to be editable without a code release.
The estimate should identify the work, assumptions and responsibilities on both sides. We can shape a first phase around the highest-priority outcome, with additional work planned separately once the relevant decisions have been made.
Share your starting pointDefine a first release people can finish
Start with one complete workflow: a customer submits a request, a coordinator reviews it, and both can see what happens next. Define the records, roles, notifications and administrative steps needed to finish that work. We can map these decisions into a prototype and a proposed first-release scope, then keep later features in a separate backlog.
For a SaaS product, the journey may include organization setup, invitations, subscription access and an admin view. For a marketplace, it may include onboarding, discovery, allocation and payment status, as in HFS. We identify the useful outcome and its acceptance conditions before estimating individual screens. Reporting, imports and staff corrections also need an owner in the scope.
Connect roles, records and integrations
React, Next.js and TypeScript can support the interface, while APIs, authentication and the database enforce the application’s rules. We choose the structure around your workload and existing systems. Some products need public, indexable pages alongside a private workspace; others need a focused internal tool. Those surfaces have different access and discovery requirements.
Permissions must be enforced where data is read or changed, including organization boundaries and administrative actions. We review account recovery, invitations, file access, validation and the states a user sees when an operation fails. A billing integration also needs a defined relationship between payment status and access. Provider setup and recurring charges are discussed separately from development work.
A working integration early in the build can expose constraints before the interface depends on it. We confirm available APIs, sandbox access, record ownership and recovery behaviour for payments, CRM records, notifications or other services. If a user can submit a request twice or a vendor is unavailable, the product needs an understandable result rather than an ambiguous success screen.
Explore API integration scopeAgree release checks and ongoing ownership
Review the app with realistic records and each important role. The agreed checks can cover onboarding, editing, restricted actions, subscription changes, loading and recovery, as well as mobile layouts and keyboard interaction. A staging setup gives your team a place to review the next release before production changes reach customers.
We document the repository, deployment process, account ownership and the operational information included at handover. Data export, backup and recovery needs should be decided against the product’s actual records. For an inherited application, we first reproduce a build and review the affected journeys, then propose targeted changes or a staged modernization with a defined transition.
How delivery works
Understand the work
We start with your users, business model and current constraints. Bring an idea, a running product or a workflow that causes friction. Together we identify what needs to change and what a useful first outcome looks like.
Shape a practical scope
We connect the user journey to the design, engineering and operational work it needs. Assumptions, dependencies and responsibilities are discussed early, so you can make informed decisions about the first release and the work that follows.
Build with visible progress
Designs, prototypes and working features give us something concrete to discuss. We review progress with you, resolve questions as they arise and test the important journeys. Changes to priorities are considered against the agreed scope.
Launch and keep improving
Release preparation includes the agreed testing, deployment and handover. We make support responsibilities clear and can continue as your product team, improving the experience as you learn from real use and plan the next release.
Prepare the decisions behind your project.
Prepare the scope and implementation decisions behind a custom application.
Build a budget you can check
Compare role hours, scope assumptions and acceptance conditions rather than a headline price.
Read the guidePlan organization access boundaries
Work through tenant membership and permission tests before releasing a shared SaaS workspace.
Read the guideConnect subscriptions to access
Define billing states and a recovery path for events that arrive late or more than once.
Read the guideImprove an inherited product
Assess incremental changes and the conditions that justify replacing part of the application.
Read the guideFrequently asked questions
Can we start with one workflow and expand later?
Yes. We can define a complete initial journey and keep later features in a prioritised backlog. The architecture should account for known dependencies, while the first release remains focused enough to review and test properly.
Can you build both the customer app and our admin workspace?
Yes. We map the actions and data each role needs, including who handles exceptions. HFS is a relevant example with freelancer, company and administrator journeys. The proposal identifies the included roles, screens, permissions and operational steps so the admin side is part of the product scope.
Do we need a custom application or an existing platform?
We first compare your workflow with what an existing tool can support. A custom application makes sense when your roles, records, integrations or interface need meaningful differences. The first phase can assess those constraints and prototype the difficult journey before committing to a larger build.
Can you add subscriptions and billing?
We can scope billing, access rules and administrative recovery together. We confirm the provider, account ownership and subscription states, including changes, failed payments and cancellation. The estimate includes the agreed integration and acceptance checks; transaction fees and other vendor charges are identified separately.
What information do you need for an estimate?
Share a complete example of the task, the roles involved, important records, integrations and what already exists. Include content or design responsibilities, timing and a budget range. We turn those inputs into proposed deliverables, acceptance conditions, dependencies and a first release you can review.
Can our team maintain the product after handover?
The proposal defines source-code ownership, account access, release notes and the documentation or training included. We identify who will deploy changes, maintain dependencies and respond to incidents. Your own team can take over, or an ongoing engagement can support the backlog and maintenance responsibilities.
Can this be a focused engagement within our existing product?
Yes. We can scope this work around an existing product after reviewing the relevant design, code or operating setup. We identify the dependencies and agree what is included, who provides access and how the change will be reviewed. If another part of the product also needs work, we explain that before expanding the scope.