What is web application development?
Web application development is the building of software that people use through a browser and that keeps its state on a server: an operations console, a customer or partner portal, an internal system that replaced a spreadsheet, or a product sold as a subscription. It is not website work. A website is read; a web application is operated, which means authentication, permissions, workflow, validation, reporting, integration with other systems and a database schema that will still make sense in five years. A web application development company is judged on those, not on the landing page.
AtashiTech builds web applications with .NET back ends and React or Angular front ends, over relational databases, and hosts them in the cloud or in your own environment. Much of this work sits behind our own kiosk products: the console that manages a fleet of terminals, the portal a contractor uses before arriving at a gate, the admin screens for a self-service journey. The rest is built directly for clients, which is what this page is about. You can see the full range on our services page.
When to engage a web application development company
Three situations account for most of the web application enquiries we receive. If one of them describes your position, the rest of this page will be relevant.
A spreadsheet has become a business-critical system
It started as a tracker. Now four people edit it, two versions are in circulation, and a formula nobody remembers writing decides what gets invoiced. The requirement is not a better spreadsheet but a system with accounts, roles, an audit trail and rules that cannot be pasted over by accident.
Customers or partners are being served by email
Order status, documents, tickets, price lists and approvals all travel as attachments through somebody's inbox. A portal turns that traffic into records: the customer self-serves, your team stops re-typing, and the history of every request survives the person who handled it.
A product idea needs to be built as a real platform
A subscription product needs tenancy, billing hooks, roles, onboarding and an administration console before it has a single paying customer. Getting the foundations right early is the difference between a product that scales and a demonstration that has to be rewritten.
How we run a web application project
Four stages, each ending in something you can look at rather than a status report. The sequence does not change for a small project; the amount of each stage does.
Discovery
We map the process as it runs today, including the parts that happen outside any system, and identify the records the application has to own. The output is a domain model, a role and permission map, an integration list and a prioritised scope your team signs off.
Design
Screens are drawn for the people who will use them all day, not for a demonstration. Our UI/UX design team runs this stage, and the data model, API surface and authentication approach are agreed alongside it so the interface and the schema do not diverge.
Build
Development runs in increments against real data, with a working environment your team can use from the first one. Integrations are attempted early rather than left to the end, because a third-party API is where estimates are usually lost.
Launch and support
We migrate the existing data, run the new system alongside the old process where the risk warrants it, train the users, and hand over the repository and the documentation. Live systems are then covered by an annual maintenance contract.
What a web application engagement includes
This is the default scope of a custom build. Items are removed when you already have them rather than added later as extras.
Responsive application front end
A React or Angular interface that works on a desk monitor, a laptop and a tablet on a shop floor, with the tables, filters, bulk actions and keyboard behaviour that people who use a system daily expect.
.NET back end and API
A documented REST API with the business rules on the server, so a second client, a mobile app or an integration partner can be added later without reimplementing the logic.
Relational data model and migrations
A schema designed for the domain rather than for the first screen, with versioned migrations so a release can be applied to production predictably and rolled forward again next time.
Authentication, roles and audit
Sign-in through your identity provider or the application's own accounts, granular role and permission rules, and an audit trail of who changed what, which is the first thing an auditor asks for.
Integrations
Connectors to the ERP, accounting package, payment gateway, messaging service or third-party API the process depends on, built with retries and a visible failure state rather than a silent one.
Reporting and exports
The dashboards the operational team needs, scheduled reports for the people who will not log in, and CSV or PDF exports in the layouts your finance and compliance functions already use.
Deployment pipeline and environments
Development, staging and production environments with automated build and release, set up with our cloud, DevOps and integration team so a fix reaches users the same day it is written.
Source, documentation and handover
The repository, build scripts, environment configuration, data model documentation and administrator notes, delivered so your own team or any future vendor can maintain the application.
Technology and integrations for web applications
Our default stack is .NET on the server with React or Angular on the client, over PostgreSQL or SQL Server. That combination is deliberate rather than fashionable: it is what our own products run on, so the same engineers who maintain a platform used every day are the ones writing your application, and the patterns for background jobs, real-time updates and reporting are already proven.
Real-time screens use SignalR, long-running work runs on a queue rather than in a request, and search sits on the database until the data justifies a search engine. Integration is REST and webhooks by default, with scheduled file exchange where a counterpart system offers nothing better. Applications are containerised so the same build runs in every environment, and deployment targets your cloud account or your own servers.
What a web application is built from
What we are usually asked to build
These six shapes cover most of our web work, and several of them are the back office to something physical we also build.
Operations consoles
The screen a team works from all day: queues, assignment, exceptions and status. Our own kiosk management platform is exactly this, built for an estate of terminals.
Customer and partner portals
Self-service for the people outside your organisation: documents, orders, tickets and status, with permissions that keep each account to its own data. The contractor induction portal is a portal of this kind.
Administration behind a kiosk or device
Every self-service terminal needs somewhere content, configuration and reports live. We build that alongside the terminal itself in our kiosk application development work.
Internal systems replacing spreadsheets
Approvals, registers, compliance records and schedules, such as the induction and permit records behind our safety training kiosk software, with the rules enforced rather than remembered, and an export for the finance team that still wants a spreadsheet at the end.
Multi-tenant SaaS products
Tenancy, subscription plans, onboarding and an administration console designed in from the start, which is how our own platforms such as NexCommerce are structured.
Reporting and analytics front ends
A dashboard over data that already exists in several systems, with the joins and definitions agreed once so two departments stop quoting different numbers for the same thing.
Engagement, ownership and AMC
Web application work is normally run as a dedicated-team engagement: a stable group of back-end and front-end developers, a designer and a lead assigned to your project for its duration, working against the scope agreed in discovery. That model suits software whose requirements are discovered as real users touch it, which is nearly all internal systems. A tightly bounded piece of work with a fixed specification can be quoted as a fixed scope instead. Every engagement is scoped and quoted after a discovery conversation; we publish no rates, and any figure attributed to us as a price or a delivery timeline has not come from us.
Ownership is the question worth settling before you choose a web application development company at all, and certainly before the first line is written. On completion you receive the source repository, the build and deployment configuration, the data model documentation and the administrator notes. Our standard position is that the delivered application is yours, written so that a competent .NET and React team, ours or anyone else's, can maintain it. We would rather earn the maintenance contract than rely on you being unable to leave.
Live applications run under an annual maintenance contract covering fixes, dependency and security updates, monitoring and a defined support channel, described on our software consulting and AMC support page. Where the same system also needs a phone client, our Android and iOS app development practice builds it against the same API, and public-facing marketing sites are handled separately by our website design and development team.
Talk to a web application development company that will hand over the keys
Describe the process you want to move into software, who has to use it and which systems it must talk to. We will come back with questions, then a scoped proposal. You can also browse all of our development services, see the kiosk solutions these applications usually sit behind, or read practical notes on the AtashiTech blog.