HomeWeb Application Development
Web Applications
A website tells people things. A web application lets them do things. The gap between the two is mostly invisible, and it is where the budget goes.
KYVEON builds custom web applications: dashboards, portals, booking systems, internal tools, calculators, and the operational software that businesses end up running on. This page is mostly about how to tell whether you need one, because a surprising number of people asking for a web app need a website, and a smaller number asking for a website have already outgrown one.
The distinction is not size and it is not how it looks. It is state.
A website presents the same content to everyone. Its content changes when someone edits it. If two people load the same page, they see the same thing. Everything the site knows, it knows in advance.
A web application holds state that changes because of what users do. It knows who you are, remembers what you did last time, shows you something different from what it shows the person next to you, and enforces rules about what you are allowed to do. The moment a system needs to remember a user’s actions and act on them, it stops being a website and starts being software — with everything that implies about testing, permissions, data integrity, and failure modes.
Three questions settle it in practice:
If all three are no, you want a website and you should pay website prices — see web development services. We will tell you that on the first call rather than scoping something larger.
Sign-up, sign-in, password reset, email verification, session handling, and the tedious edges: what happens when someone requests two reset links, when a session expires mid-form, when a user changes the email address their account is keyed to. This is the area where teams most often reach for a shortcut, and it is the worst place to have one. We build on established, audited authentication rather than writing our own, and we treat the edge cases as part of the scope rather than as bugs to discover later.
Almost every application grows more than one kind of user — admin, staff, customer, read-only, someone’s accountant who should see invoices and nothing else. The decision that matters is made early: are permissions checked in one place the whole system consults, or scattered through the interface?
Scattering them is faster for the first three roles and progressively catastrophic afterwards. Every new feature needs permission logic added in several places, and the failure mode is silent — a page that forgot its check exposes data to the wrong user and nothing complains. We centralise authorisation from the first version, enforce it on the server rather than by hiding buttons, and treat the client as something that can lie.
This is the decision with the longest shadow. A schema modelled properly makes features cheap for years; one rushed to hit a demo date becomes the reason a straightforward request costs a fortnight two years later.
The specific mistakes are consistent and worth naming: storing structured information in free-text fields because it was quicker; assuming a one-to-one relationship that turns out to be one-to-many, so a customer can only ever have one address until someone needs two; destroying history by overwriting records rather than versioning them, so nobody can answer what a price was in March; and using a natural identifier like an email address as a primary key, which works right up to the first person who changes theirs.
We model the data before we design screens. It is not the fun part of the project and it is the part that determines what the product costs to own.
Even when the application is one system, a clear API between the interface and the logic is worth having: it makes the system testable, lets a mobile app reuse the same backend later, and stops business rules being smeared into the interface where they get duplicated and diverge. If you might later want an app, say so at scoping — designing the API for two consumers from the start costs little, and retrofitting it costs a lot. Our mobile app development projects frequently reuse an API we built for the web application first.
The most common brief we receive is “a dashboard showing everything”, and it is the most common thing we push back on. A dashboard showing everything gets read once. A useful dashboard answers a specific question a specific person has at a specific moment — what needs my attention today, what changed since yesterday, what is about to breach a deadline — and shows nothing else. We ask who opens it, how often, and what they do next, then build for that. Reports and exports handle the rest.
In roughly the order they cost you:
None of these need gold-plating. They need deciding deliberately, in writing, before code is written — which is exactly what the scoping stage is for.
Server-side validation on everything, because client-side validation is a convenience and not a control. Parameterised queries throughout. Secrets in environment configuration, never in the repository. Errors logged with enough context to diagnose, without logging personal data. Backups that are restored to a scratch environment on a schedule rather than assumed to work. Documentation written as the system is built, so the next engineer — possibly not us — can pick it up.
That last point is deliberate. Custom software is a long-term commitment and you should not be locked into the people who wrote it.
Applications are scoped by the operations a user can perform and the rules behind them, not by screen count. Ten screens that mostly display data is a smaller project than four screens with approval workflows, role-based visibility, and a payment integration.
Web application work generally starts around PKR 175,000 and rises with the number of user roles, integrations, and the complexity of the business rules. Before development begins you get a written scope, a fixed price, and a timeline, with payments split across milestones. Changes are quoted in writing before they are built.
For genuinely large systems, we scope a first version deliberately narrow — the smallest thing that is useful to real users — and add from there. This is not a way to charge twice. It is because the requirements you write before anyone has used the system are always partly wrong, and finding that out after eight weeks costs far less than finding it out after eight months.
If a spreadsheet is currently doing the job and the only real complaint is that two people cannot edit it at once, a shared cloud spreadsheet solves that today for nothing. If the process changes every month because the business is still working out how it operates, custom software will be obsolete before it launches — wait until the process is stable. And if an off-the-shelf product covers eighty percent of what you need, adapting your process to it is almost always cheaper than building and then owning the remaining twenty.
Custom software earns its cost when the process is a genuine competitive advantage, when off-the-shelf options force compromises that actually hurt, or when licence fees at your scale exceed the cost of owning something. We would rather establish that on a free call than sell you a system you regret.
Source code, database schema and migrations, design files, API documentation, and every account transfer to you on final payment. The system runs on your infrastructure under your accounts. Any competent engineer can take it forward. With custom software that is not a nicety — it is the difference between an asset and a dependency.
Proof
A 109-page, compliance-aware architecture on Astro for a US state-licensed CPA firm — built to reach a national audience without ever claiming a local office it does not have.
A 50+ page, two-market website for a tax, corporate and legal consultancy — US accounting and Pakistan legal in separate lanes. Designed, built, launched and maintained end to end.
Both builds are documented end to end in the full portfolio.
FAQ
State. A website shows everyone the same content, and it changes when someone edits it. A web application holds state that changes because of what users do — it knows who you are, remembers what you did, and enforces rules about what you may do. Three questions settle it: does anyone log in to use it, does the system make decisions, and would losing the data hurt? If all three are no, you want a website.
Generally from PKR 175,000, rising with the number of user roles, integrations, and the complexity of the business rules behind the screens. Applications are scoped by the operations users can perform rather than by screen count — four screens with approval workflows and a payment integration is a bigger project than ten screens that mostly display data. You get a fixed scope and price in writing before development starts.
Yes, if we know at scoping. Designing the API for two consumers from the start costs very little; retrofitting it once business logic has settled into the web interface costs a lot. Tell us a mobile app is likely and we will structure it accordingly — several of our app projects reuse an API built for the web application first.
Authorisation is centralised from the first version and enforced on the server, not by hiding buttons in the interface. That is slightly more work for the first two roles and dramatically less for every role after, and it removes the failure mode where a page forgets its permission check and quietly exposes data to the wrong user.
For anything substantial, start narrow — the smallest version that is genuinely useful to real users — then extend. Requirements written before anyone has used the system are always partly wrong, and discovering that after eight weeks costs far less than discovering it after eight months. We scope the first version deliberately tight for that reason, not to bill twice.
Then use it. If a product covers around eighty percent of what you need, adapting your process to it is almost always cheaper than building and owning the other twenty percent forever. Custom software earns its cost when the process is a real competitive advantage, when the compromises off-the-shelf forces genuinely hurt, or when licence fees at your scale exceed the cost of ownership. We will tell you which situation you are in.
Tell us what people do today, where it breaks, and who is involved. We will come back with an honest read on whether that is a website, an application, or a spreadsheet you already have.
Scope My Application