Web application development for a process no boxed system fits.
A client portal, a partner portal or a subscription product, built on your processes. It ships in stages, you try each stage as it lands, and the full source code is handed over at the end.
12+ projects delivered
every one on deadline, in production
Fixed price and deadline
in writing, and if we slip, the next payment waits
Reply within 24 hours
on working days, to every enquiry
In writingFixed quote after scoping
The first call settles the scope, and the proposal breaks it into stages.
What you run into today
Every new order gets typed in three times: the shop, the sheet, the invoicing tool.
Your customers email to ask where their order stands, because there is no screen where they could look.
You pay per seat for ten users, and the process still does not fit the boxed system.
You have a system, and every small change puts you in your vendor's development queue.
Which one is your situation?
Customers email to ask about orders
Client portal: they sign in to see their documents, invoices and order status.
Partners phone for the price list
Partner portal for resellers and suppliers: their own price list and their own orders.
A service you would sell monthly
Subscription product: sign-up, plans and billing in one system.
You bring sellers and buyers together
Marketplace: the offers, the search and the transaction between them, on one moderated surface.
Customers would build their own quote
Configurator: customers assemble their own version by your rules, and get a price.
Who sees what, and who can change it
A portal works when everyone reaches exactly what their job needs, and the first call settles your own split of roles.
Your customer
Your team
Approver
Administrator
Opening their own documents, invoices and orders
yes
yes
yes
yes
Every customer on one surface
no
yes
yes
yes
Adding and editing records
no
yes
yes
yes
Reports and usage numbers
no
yes
yes
yes
Approving high-value lines
no
no
yes
yes
Inviting users, setting permissions
no
no
no
yes
Opening their own documents, invoices and orders
Your customer: yes
Your team: yes
Approver: yes
Administrator: yes
Every customer on one surface
Your customer: no
Your team: yes
Approver: yes
Administrator: yes
Adding and editing records
Your customer: no
Your team: yes
Approver: yes
Administrator: yes
Reports and usage numbers
Your customer: no
Your team: yes
Approver: yes
Administrator: yes
Approving high-value lines
Your customer: no
Your team: no
Approver: yes
Administrator: yes
Inviting users, setting permissions
Your customer: no
Your team: no
Approver: no
Administrator: yes
In a small team the approver and the administrator are often the same person.
What a web application project includes
- The screens and the system behind them, from one team
- A version you can try on a live link at every stage, with your own data
- A foundation that holds as traffic and users grow
- Source code, credentials and documentation at handover
This is what lands after the call
An itemised scope, one amount, the payment schedule and a signature row. This sheet is what makes a custom build predictable.
A sample online store quote, with an invented client. A web application quote is built the same way: itemised, one sum, a payment schedule.
What your team and your clients open
Each module replaces work someone does by hand today, and anything that replaces nothing does not get built.
Subscription and payment
A monthly fee, card payment and invoice, connected to your invoicing.
Quote builder
Clients put their own quote together, and you approve it before it goes out.
Notifications
The system speaks up when an order or a request changes state.
Admin for your team
Your team manages clients, items and settings in one place.
Roles and permissions
Set per user: who sees what, and who can change it.
Reports and usage
See who uses what, and where the process gets stuck.
Where the company's data actually sits today
The day-to-day operating data starts in one spreadsheet, and it stays there long after the company has outgrown it.
of the SMEs surveyed
69%
Primarily a spreadsheet
31%
Somewhere else
Who should build it
A custom web application can be bought from several places, and you live with whoever builds it for years.
In-house developer
Freelancer
Hourly agency
Brecon
Who is accountable for the deadline
You are. They estimate; your company carries the consequence.
Whatever you agree. With no deadline in writing there is nothing to hold.
An hourly rate covers the effort; the date stays an estimate.
Us. Each stage has its deadline in the proposal, and if we slip, the next payment waits.
What happens if the person leaves
The knowledge leaves with them unless it was written down. A new hire, a new ramp-up.
One person, one calendar. If they disappear, the project stops.
People can be swapped, and the ramp-up still takes time.
Handover includes the source code, the accounts and the documentation, so the next team does not start from zero.
What happens to the code
Yours, as it is written.
Depends on the contract. One sentence in it settles the question.
Depends on the contract, and licences and accesses are part of the question.
Yours, with the accounts, on the final invoice, and another team can carry the extensions.
When this is the better choice
When development runs for years and someone is there to direct it daily.
For small, precisely described work this is often a sound choice.
When the scope only becomes clear as you go and you can carry an open budget.
When a bounded system has to be built, and you would build an in-house team for what follows.
Who is accountable for the deadline
- Brecon
- Us. Each stage has its deadline in the proposal, and if we slip, the next payment waits.
- In-house developer
- You are. They estimate; your company carries the consequence.
- Freelancer
- Whatever you agree. With no deadline in writing there is nothing to hold.
- Hourly agency
- An hourly rate covers the effort; the date stays an estimate.
What happens if the person leaves
- Brecon
- Handover includes the source code, the accounts and the documentation, so the next team does not start from zero.
- In-house developer
- The knowledge leaves with them unless it was written down. A new hire, a new ramp-up.
- Freelancer
- One person, one calendar. If they disappear, the project stops.
- Hourly agency
- People can be swapped, and the ramp-up still takes time.
What happens to the code
- Brecon
- Yours, with the accounts, on the final invoice, and another team can carry the extensions.
- In-house developer
- Yours, as it is written.
- Freelancer
- Depends on the contract. One sentence in it settles the question.
- Hourly agency
- Depends on the contract, and licences and accesses are part of the question.
When this is the better choice
- Brecon
- When a bounded system has to be built, and you would build an in-house team for what follows.
- In-house developer
- When development runs for years and someone is there to direct it daily.
- Freelancer
- For small, precisely described work this is often a sound choice.
- Hourly agency
- When the scope only becomes clear as you go and you can carry an open budget.
How the application ships, stage by stage
- Call
We walk your processes
We look at how many processes and roles go in, and what it has to connect to. At the end we say which one is worth starting with.
- Scoping
An itemised proposal in writing
You get what we build stage by stage, by when and for how much. That price holds to the end of the project, and a new request is priced first.
- Build
The system ships in stages
The process that returns the most goes first, then the rest. At the end of every stage you try it on a live link with your own data.
- Live
Launch and operations
We take it live and watch it as the traffic grows.
Who a web app fits, and who not
This fits you if
- You have outgrown the spreadsheet and the process now touches several people.
- You run a logic of your own that no packaged system follows.
- You want a system you can develop for years, with the code in your name.
We would point you elsewhere if
- A packaged tool follows the process, and the process is not the reason your customers pick you. Then the packaged tool is the better buy. We say so on the first call.
- One form and a thank-you page is the whole goal. That is a landing page, at a fraction of the price.
If the process is closer to stock, customer records or approvals, that is an internal system.
80%
of the features in the average software product are rarely or never used. You still pay for every one of them.
Pendo, 2019: real usage data from 615 software products.
Companies we've built for
How we work
A custom web application, from design to operations
- Clickable progress on a live link, stage by stage
- Fixed price and deadline in writing, and if we slip, the next payment waits
- The code and the infrastructure are yours
In writing
Fixed quote after scoping
The first call settles the scope, and the proposal breaks it into stages.
How big is the product, and what goes into the first round? We usually start with a narrow first version and extend it.
Get a fixed-price quoteWhat happens after launch
A live web application starts to strain where the traffic and the user count grow, and that is exactly what we keep watching after handover.
First month
A clean handover, a watched launch
Source code, credentials and documentation in your hands, and we watch the first week with you, measurements included.
Every month
Maintenance that keeps it moving
Updates, fixes, extensions, and an eye on the measurements.
If something breaks
You write, we answer
A first reply within 24 hours on working days, to every enquiry.
The cost, the scope and the ownership questions
The price list says "Fixed quote after scoping", and scope is what decides it: how many processes go in, how many roles there are, which systems it has to talk to. After the first call you get an itemised proposal with an agreed figure and a deadline, broken into stages, and that figure holds to the end of the project.
All of it is yours. The account that holds the code and the cloud accounts are in your name, and we work inside them as invited collaborators. Access transfers with the final invoice, and the system keeps running if we step away.
It depends on scope, so the deadline comes from the proposal after scoping, broken into stages, in writing. The clock starts once every piece of information is in, and each stage ends on a live link you open and test.
Before launch you get a maintenance quote of its own: updates, fixes and extensions as the system lives on. A new module is a separate proposal on the same logic, and we design the system so that it does not mean rewriting half of it. We answer within 24 hours on working days. The code and the infrastructure are yours throughout, so your own team can take over maintenance at any point.
If you will be developing continuously for years, an in-house hire is a good path, and they inherit our documented code. The build itself needs a developer, a designer and testing at once, and hiring takes months. We build to an agreed figure and a deadline set in writing, and your future hire takes over a finished system.
If twenty customers sign in each month for the same three things, a ready-made portal costs less, and the review will land there too. Ready-made products bill per user or per account, which gets expensive with hundreds of customers who sign in twice a year. The other boundary is the process: where your own process does not fit the product's box, the workarounds stay with your team, and your team pays for them.
A good share of software projects do, usually because they start from an hourly estimate. Our proposal is one agreed figure: what we build, by when, for how much. If a new requirement comes up mid-project we price it first and you decide. Anything that slips inside the agreed scope is our risk.
Start with your processes
In half an hour we walk through what your company still does by hand, then you get an itemised proposal in stages.
- 12+ projects deliveredevery one on deadline, in production
- Fixed price and deadlinein writing, and if we slip, the next payment waits
- Reply within 24 hourson working days, to every enquiry