Custom business software

Software built around the way your business works.

A customer portal, an internal tool or a specialised application—built around a real job.

Keep the systems that fit. Build what is missing, with clear user roles, reliable connections and a plan for ownership and maintenance.

Discuss a software project ↗

Ways to work together

Choose a project you can put to work.

Start with the result you need. These are starting points for a scoped engagement, not fixed packages. The quote defines the deliverables, boundaries and success test for your project.

Internal business application

For staff whose work no longer fits a spreadsheet or disconnected tools.

Deliverables, scope & handover

Deliverables: A usable application for one agreed job, including roles, records and the required reports or connections.
Scope & cost drivers: User roles, business rules, migration, integrations and reliability needs—not just screen count.
Success test: Staff complete the agreed job end to end; invalid inputs, access boundaries and recovery paths behave as specified.
Handover: The agreed source and deployment materials, data structure, operating instructions and known limitations.

Customer or partner portal

For businesses that need to share requests, files, decisions and progress with outside users.

Deliverables, scope & handover

Deliverables: A portal and staff workflow for agreed request types, with account access and a shared history.
Scope & cost drivers: Permission boundaries, file handling, approval steps, branding and connections to internal systems.
Success test: Each user sees only permitted records, and a request can be submitted, reviewed and followed through without losing its version history.
Handover: The agreed application files, access administration guide, integration notes and release documentation.

Client-facing software product

For a business turning a specialised service or idea into software its customers can use.

Deliverables, scope & handover

Deliverables: A focused first release covering the core customer journey and the administration needed to operate it.
Scope & cost drivers: Customer types, account separation, onboarding, usage levels and any billing or third-party dependencies.
Success test: Representative customers complete the core journey and operators can manage accounts and exceptions against agreed release criteria.
Handover: The agreed source, build and deployment instructions, dependency inventory and a prioritised list of remaining work.

How scope becomes a quote ↗

Illustrative example / Customer portal + staff workflow

One request. Two views. A shared history.

A customer asks for a change to an ongoing project. Email alone makes it difficult to see which file is current, who has approved the change and what happens next. A tailored portal could give the customer a clear place to request work while giving staff the controls to deliver it.

Customer view

Request, review, follow progress.

Submit a request with supporting files. See the current proposal and ask questions in context. Approve only the version presented, then follow agreed milestones without seeing internal notes or another customer’s records.

Staff view

Scope, coordinate, keep the record.

Triage the request, assign an owner and prepare the scope. A changed file invalidates an earlier review where required. The team checks capacity and confirms the schedule before publishing a customer commitment.

The same request connects files, comments, decisions and status. Notifications follow agreed rules, while access checks prevent a shared link from bypassing customer boundaries. A rejected change stays rejected; a prepared proposal is not an approval.

Illustrative system, not a packaged portal or a claim of delivered results. The first version might cover one request type and one staff team, with integrations added only where needed.

Follow the customer-portal example ↗

Build, buy or improve your spreadsheet?

A practical buying guide

Custom software or an existing product?

Compare the whole cost of operating the system—not just the cost of building its first screen. Use one representative job to test each option, including the awkward exceptions.

Configure an existing product

Best when the essential workflow fits a maintained product. Test permissions, exports, reporting and the real subscription tier you would need. Configuration can be the right answer even if a few habits need to change.

Connect the tools you have

Best when each tool does its own job well but people re-enter records between them. Check native connectors first, then API access, sync direction, error recovery and who owns the combined workflow.

Commission a custom application

Consider a build when a necessary workflow, user experience or permission model cannot be supported sensibly otherwise. Budget for migration, testing, hosting, maintenance and someone who owns the system after launch.

When spreadsheets stop being the right system

A spreadsheet may still be the best choice for a small, well-owned analysis. Improve validation, protected ranges and documentation before replacing it. Consider a different system when several people need distinct permissions, edits must trigger coordinated work, or version confusion makes decisions unreliable.

Test a packaged database or workflow tool against those requirements before commissioning software. If you do build, identify which historical rows must migrate, how formulas become tested rules and how staff will reconcile the first live records.

What changes scope and cost?

The number of user roles, integrations, migration complexity, approval rules and reliability requirements matter more than a page count. Separate essential behaviour from convenience features. We agree scope, price and acceptance criteria after reviewing those constraints; there is no universal project price or delivery promise.

Compare workflow automation and system integration ↗

Release testing & handover

Release with a clear handover

Make the first version usable—and supportable.

Walk through the complete workflow with representative users before release. Test access restrictions, incomplete inputs and connection failures alongside the happy path. Agree the migration and rollback approach, operating documentation and responsibility for support. A successful demo is the beginning of acceptance, not a substitute for it.

Explore AI consulting when the application needs company knowledge ↗

Start with one project.

Tell us what you want to improve. We’ll compare approaches and agree on the scope, price and what success looks like before building. You don’t need a technical brief.

Pricing & working together ↗

Discuss a software project ↗