Everything from one team
Design, build and operations with the same team, from the first call to launch.
Web application development: portal, SaaS or internal platform
SaaS platform, client portal or subscription product, built on your processes. You get a clickable build at every stage and the full source code 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 writingQuoted after scoping
The first call settles the scope, and the proposal breaks it into stages.
What you run into today
Your customers email to ask where their order stands, because there is no screen where they could look.
Every new order gets typed in three times: the shop, the sheet, the invoicing tool.
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 of these is your project
Client portal
Your customers get a sign-in of their own, with their documents, invoices and order status behind it, and an alert when something changes.
Partner portal
The same for resellers and suppliers: their own price list, their own orders, and only what concerns them.
SaaS or subscription product
Sign-up, plans and billing, with several customers in one system, their data kept apart, and usage reporting of their own.
Marketplace
Two sides meet on one surface: the side offering, the side searching, the transaction between them and whoever moderates it.
Quote configurator
Your customer assembles their own version by the rules, and gets a price and a summary of it at the end.
Who sees what, and who can change it
A portal works when everyone reaches exactly as much as their job needs. This is the default split of roles; the exact one is settled on the first call.
Your customer
Your team
Approver
Administrator
Opening their own documents, invoices and orders
Your customeryes
Your teamyes
Approveryes
Administratoryes
Every customer on one surface
Your customerno
Your teamyes
Approveryes
Administratoryes
Adding and editing records
Your customerno
Your teamyes
Approveryes
Administratoryes
Reports and usage numbers
Your customerno
Your teamyes
Approveryes
Administratoryes
Approving high-value lines
Your customerno
Your teamno
Approveryes
Administratoryes
Inviting users, setting permissions
Your customerno
Your teamno
Approverno
Administratoryes
In a small team the approver and the administrator are often the same person. That is a first-call question too.
What a web application project includes
- Front end, back end and database, from one team
- Sign-in and roles: who sees what, who can change what
- Live status, and a notification the moment something changes
- Wired into payments, your CRM and your invoicing
- An admin screen for your team, with usage figures
- A database architecture that carries growing traffic
Example
For a 20-person wholesaler we would start with order entry: per-partner price lists, stock reserved the moment an order lands, and an approval step on high-value lines. The warehouse ticks off picking on a tablet, and invoicing keeps running in the system you already have. Reporting goes into the second stage.
What the application is built on
This stack fits a system that needs sign-in, roles and people working in it at once: permissions are enforced in the database as well, and Zod validates every incoming value.
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.
Where the company's data actually sits today
In most Hungarian SMEs the day-to-day operating data is assembled primarily in a spreadsheet. That is why the same record ends up in three places, and why nobody can say which version is the current one.
of the Hungarian 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 instalment 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.
- 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.
- Brecon
- Us. Each stage has its deadline in the proposal, and if we slip, the next instalment waits.
- 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.
- Brecon
- Handover includes the source code, the accounts and the documentation, so the next team does not start from zero.
- 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.
- Brecon
- Yours, with the accounts, on the final invoice, and another team can carry the extensions.
- 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.
- Brecon
- When a bounded system has to be built, and you would build an in-house team for what follows.
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 custom web application fits, and who it does 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, CRM or approvals, the internal systems page covers that.
85-90%
of the features in packaged systems are never used. You still pay for all of them.
This figure comes from industry research.
Companies we've built for
Gloster
Palm Group
Habibi
The Garage
Design Glass
Kék Padlizsán
Jungle Burger
D+D Solar
Fawa
On every project
Your goal sets the bar
The first call is about what you want to achieve; if less will get you there, we say so.
Tested before it goes live
We measure what we hand over before launch, and watch the first week with you, measurements included.
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
- The code and the infrastructure are yours
- Monthly maintenance after launch: updates, fixes, extensions
- If we slip, the next instalment waits
The proposal is itemised: what we build, by when, for how much.
In writing
Quoted after scoping
The first call settles the scope, and the proposal breaks it into stages.
The size of 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. We watch the first week with you, measurements included.
Every month
Maintenance that keeps it moving
Updates, fixes, extensions, and the measurements watched as your product grows.
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 "Quoted 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.
An extension is a separate proposal on the same fixed-price logic. We design the architecture so that a new module does not mean rewriting half the system. The code is yours, so you can continue with another team.
All of it is yours. The repository 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. 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 codebase. 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 and what a system could take over. Then you get an itemised proposal, split into stages.