Secondary service
Custom Software Development
Focused software built around a clear business outcome — internal tools, dashboards, portals, APIs, integrations, SaaS features, and bounded applications where the requirements are genuinely understood.
Secondary service
Building is the easy part. Knowing when to build is not.
Most requests that arrive as “we need this built” are better served by repairing or completing what already exists. When custom development genuinely is the right answer, this is that engagement.
BrightPocket leads with recovery because that is where the harder judgment lives and where most businesses are actually stuck. Custom development is a real service here, offered selectively — not the front door.
Who this is for
- Businesses with a specific outcome and enough clarity to define acceptance criteria
- Teams needing an MVP completed rather than started over
- Anyone who needs a bounded build with a real handoff at the end
What you receive
- Scope, acceptance criteria, and exclusions agreed before implementation
- Milestone-based delivery for larger engagements
- Testing appropriate to what is being built
- Maintainable handoff — code someone else can pick up
What this does not include
Stated plainly so there is no ambiguity later. Anything here can be scoped separately if you need it.
- Open-ended "build anything" projects
- Fixed-price work with undefined scope
- Unlimited development capacity or cheap hourly coding labour
The outcome
Working software that meets criteria agreed in writing before it was built.
Fit
What this is well suited to
Work where the business outcome is clear enough that we can write down what “done” means before starting.
Internal tools
The spreadsheet-and-email process that has outgrown itself and now needs to be a real application.
Dashboards and reporting
Pulling data you already hold into something a person can act on, rather than export and reformat by hand.
Portals
A bounded surface for clients, partners, or staff to see and do a specific set of things.
APIs and integrations
Making two systems that were never designed to talk to each other work together reliably, including when one is down.
SaaS features
A defined addition to a product that already exists and already has users.
MVP completion
Something 70% built that stalled. Frequently this is really a recovery engagement wearing a build request.
Workflow applications
Software shaped around a process that a business already runs and already understands.
Focused greenfield
A genuinely new build where requirements are mature — not being discovered as we go.
The boundary
What “we build anything” actually costs you
An agency that accepts every project has to price for the ones that go wrong. That premium is paid by the clients whose projects go well, and the ones that go wrong still go wrong.
We decline work where the requirements are not yet understood enough to define acceptance criteria. That is not caution for its own sake — a fixed price against an undefined scope is a disagreement with a delayed start date.
When requirements genuinely are still forming, the honest first step is usually a short paid discovery or a Rescue Triage on what exists — not a build contract.
How an engagement runs
- 1. Outcome. What the business needs to be true when this is finished — stated in business terms, not feature lists.
- 2. Scope and criteria. What will be built, what will not, and how we will both know it is done. Agreed in writing first.
- 3. Milestones. Larger engagements are split into funded milestones with acceptance at each, so neither side carries the whole risk.
- 4. Build and verify. Small reviewable changes, tests appropriate to what is being built, verified where it will actually run.
- 5. Handoff. Documentation written for whoever maintains it next — on the assumption that person is not me.
About this price
Custom quote, because a published rate card for bespoke work is either padded or wrong.
Quotes consider the business value, scope and uncertainty, implementation effort, testing, integrations, deployment, production responsibility, communication overhead, risk, and where support ends. Larger engagements are milestone-based rather than one lump sum.
On AI-assisted delivery
Faster, and still accountable
AI is used heavily here and it makes delivery considerably faster. That speed is passed on in scope and timeline rather than hidden.
What does not change: the review, the testing, the verification, and who is responsible when something is wrong. AI output is not proof, and it is not the accountable party.
If you are here because an AI-assisted build stalled, that is a situation we know well — and it is usually recoverable rather than something to start over.
Before you commission a build
Three questions worth answering honestly, whoever you hire:
- Can you describe what success looks like without describing the software? If not, the requirements are not ready yet.
- Does something already exist that does most of this? Completing it is usually cheaper and faster than replacing it.
- Who maintains it afterwards? A build that only its author can change is a liability with a delivery date attached.
Describe your project
Tell us what you are dealing with. If this is not the right fit, we will say so and point you at what is.