Custom Digital Platforms

Build the tool your
business is missing.

We build portals and applications around one agreed task, from working out the requirements to a tested release people can use. First we check whether an existing product, or an extension to one, would do the job. When it won’t, we build what’s needed and no more.
Talk about your platform
Explore the kinds of tasks we can discuss

What should people be able to do?

Forget the feature list for a moment. Start with a person and a task they need to finish.

A customer needs to see where their job is up to.

A portal for agreed information and requests.
The question to settle

What can each customer see and do?

An applicant needs to submit, and a reviewer needs to decide.

An application or approval workspace.
The question

Who supplies, who reviews, who decides, and what happens when information is missing?

An estimator needs a quote that follows the pricing rules.

A quoting or calculation tool.
The question

Which inputs and rules produce the answer, and who signs off that they’re right?

A team needs one place to run a process that lives in spreadsheets and email.

An internal workspace.
The question

What work gets done there, and how is its status kept current?

These are examples of what we can discuss, not a product list. Whatever the task, you’ll need one accountable owner who can explain the process, settle competing requirements and line up feedback from real users. Software can’t resolve a disagreement about how the process should work.

Use what exists. Build what is needed.

There’s a ladder, and we climb it only as far as the gap requires.
01

Configure

a product you already have.
02

Extend

it, where it covers most of the need.
03

Connect

your current tools, if the task is really about information moving between them.
04

Build

an application, when the gap justifies it.
Custom work can fit your process exactly. It also comes with responsibilities: someone has to fund changes and look after it for as long as people depend on it. A standard product can be the right call even if your process has to bend a little. Sometimes the spreadsheet is still the proportionate answer, and we’ll say that too.
The choice weighs usability, the requirements, what it depends on, the ongoing costs and your capacity to run the result. The technical approach follows from that. It isn’t decided on this page.

Complete one important task properly.

A broad idea becomes a bounded first release once five things are named:
01

The users

02

The main task

03

The information involved

04

The rules

05

What finished looks like

An application portal: version one

Made up to show how a first release is drawn. Not a client project, and not a product we sell.

In

  • An applicant can save their information, submit it and see its status.
  • A reviewer can check a submission, ask for clarification and record a decision.
  • Each applicant sees only their own material. Reviewers have the permissions agreed for them.
  • The rules are defined: what’s required, which status changes are allowed and when a submission becomes final.
  • Both people can finish their task, including the back-and-forth when something needs clarifying.

Later, if it’s justified

  • More reporting.
  • Wider integrations.
  • Other types of application.
Small doesn’t mean flimsy. Permissions, recovery and support belong in version one. Features added because they might be handy one day don’t.

Make the important decisions tangible before the full build.

Some things can’t be settled in a document: whether an interaction makes sense to the people who’ll use it, how a business rule plays out, whether a technical dependency will hold. A prototype or a limited build lets users and decision makers try it and answer properly.

Know what a prototype proves.

A clickable mockup can show
That the interaction works for people.
It shows nothing about
Permissions, calculations, integrations or how the system behaves in use.
Not every project needs one. We agree the smallest exercise that resolves a real uncertainty, then carry what we learn into the release scope.
Website Design & UX

Deliver a working service, including the parts users don’t see.

Behind every screen sit a data structure, access rules, business rules, administration and any agreed connections. We build those around the task, not around a list of technologies.
THE SCREENDATA STRUCTUREACCESS RULESBUSINESS RULESADMINISTRATIONAGREED CONNECTIONS

Acceptance is about behaviour

The user can complete the agreed task.

The system applies the agreed rules.

The administrator can run the functions in scope.

We test the routes where things go wrong as well as the one where everything goes right.

Deployed isn’t the same as in use.

Then people have to start using it. Depending on scope, that means preparing existing data, training administrators, starting with a pilot group or planning the changeover from the old process.

Show what the platform lets people do.

Enable IQ
Enable IQ had a product in mind before it had a platform: structured sales training that enterprise teams could work through at scale. Nothing on the market fitted. The platform we built serves multiple client organisations at once, gives learners AI-assisted feedback on their sales coaching and shares data with the CRM behind it. Enable IQ now sells it as a subscription where it used to bill consulting time, and we continue to support and develop it.
Read the Enable IQ story

Someone has to own it after launch.

Hosting
Maintenance
User support
Data responsibilities
Future changes

Hosting, maintenance, user support, data responsibilities and future changes each need an owner and a budget, agreed before release. Your proposal shows hosting and operating costs beside the build. Fixing defects against the agreed acceptance criteria is one thing. Further development is separate, and it’s guided by how people actually use the first release, not by a list of every feature someone once imagined.

A defined project is a complete engagement. A Growth Partnership can coordinate the platform with other priorities, and it isn’t required. The first conversation is free. Detailed requirements or feasibility work may be scoped and priced separately where it’s needed.

How do we know if we need a custom platform?

By comparing the task and its constraints with what existing products can do, before anyone commits to a build.

Possibly. We investigate the specific interfaces, permissions and information involved before saying yes.

Only if WordPress suits the requirements. It’s an option, not a default.

Yes. The first release completes one useful task. Later work is prioritised separately.

That’s agreed before release: administration, hosting, maintenance and support, each with an owner.

The task, the number of roles, the rules, the data, the integrations, how it’s verified, and how ready your decisions and material are.

Describe the task.
Leave the specification to us.

Tell us who does the work, what they’re trying to finish and where the current way falls down.
Talk about your platform
Who does the work
What they’re trying to finish
Where the current way falls down