What we build
By web application we don’t mean a corporate brochure site; we mean the tool your team works inside every day. Whether it’s order tracking, work orders, account ledgers or booking management, the software is shaped to match your process. The result is one place of record where everyone sees the same data at the same time.
We always start from your existing flow. First we clarify what the work looks like on paper, then we translate it to the screen. Projects that do it the other way round usually end with software nobody uses.
Scope tiers and timelines
Starting with the most critical flow rather than covering every process at once lowers both time and risk. The tiers below assume a clearly defined scope.
| Scope | What it includes | Time |
|---|---|---|
| First version (MVP) | One flow, one user type, basic reporting | 2-4 weeks |
| Operations dashboard | Several flows, roles, alerts, mobile access | 4-8 weeks |
| Customer portal | External user accounts, self-service screens, permissions | 6-10 weeks |
| Integrated system | Links to existing systems, data migration, reporting | 8-12 weeks |
How we work
In a discovery call we clarify your needs and goals (1-2 days). You then see the design language and flow as a prototype (2-4 days) and approve the screens before any code is written. Development takes 1-3 weeks, with a working version visible throughout. After launch we stay with you through maintenance, updates and improvements.
If you can’t describe a process step by step on paper, you can’t translate it into software correctly either.
Moving your spreadsheet data into the new application
For most businesses moving to a web application, the real data lives in spreadsheets kept for years. Those files are rarely consistent: the same customer spelt three ways, empty cells, merged columns. We plan the migration alongside development instead of leaving it to launch day.
Data migration is one of the things that moves the price. Seeing a few sample files during discovery helps us size the work properly.
Planning roles and permissions from the start
Who can see what, and who can change it, is part of the data model. Permission rules added later end up touching almost every screen, so we settle the roles at the prototype stage. In a typical operations app it looks something like this:
| Role | What they see | What they can do |
|---|---|---|
| Admin | All records, reports and the user list | Adds users, changes prices and settings |
| Team member | Jobs assigned to them and the related customers | Opens records, updates status, adds notes |
| Customer | Only their own orders and documents | Raises requests and follows their progress |
The customer-facing side: the MarketGo demo
The screens your customers use can run in the browser too. In the MarketGo demo a shopper browses products by category, fills a basket and confirms the order from their phone. There is nothing to download from an app store; opening the link is enough.
Costs that are easy to leave out of the budget
Hosting and domain
The server the app runs on and its domain are paid monthly or yearly. We recommend opening the account in your company’s name.
Email and SMS sending
Password resets, notifications and reminders usually go out through services that charge per message.
Online payments
If you take payments, plan for the provider’s per-transaction fee and the time their application process takes.
Backups
How often the database is backed up, and where the copies are kept, should be agreed before launch.
Changes after launch
Bug fixes are free for the first 30 days. New features after that run on a monthly retainer or job by job.
Frequently asked questions
How long does it take to build a web application?
It depends on scope. A working first version covering a single flow is typically ready to ship in 2-4 weeks; an operations dashboard with roles and alerts takes 4-8 weeks; a system integrated with your existing tools takes 8-12 weeks. We set a clear timeline after the discovery call.
Can you build on top of my existing system?
Yes. Besides building from scratch we add features to existing products, modernise them and improve performance. In that case the first step is reviewing the existing code and data structure; how much can be preserved becomes clear after that review.
Who owns the code and the data?
You do. Delivery includes the source code, documentation and setup instructions. We can keep maintaining it, your own team can take it over, or you can hand it to another team. Not locking you in is part of how we deliver.
Why custom software instead of an off-the-shelf product?
If your process is the same as everyone else’s in your industry, off-the-shelf is faster and cheaper. If your process differentiates you, if you need to connect several systems, or if per-seat licensing cost is growing, custom is the better fit. The most common practical path is hybrid: standard work stays in a ready-made product and the layer specific to you is built separately.
Does a web application work on phones, or do I need a mobile app as well?
The interface is designed to work on phones and tablets, which is enough for most internal operations tools. If people need to work offline in the field for long stretches, rely heavily on phone features or find you in an app store, we’ll talk about a mobile app separately.
Does the cost go up as we add users?
We don’t charge licence fees per user. What can grow with usage is hosting and the cost of sending emails or SMS messages, and we look at those together during discovery based on the usage you expect.