Web application development: portals and panels

Website or web application?

Both open in a browser; the difference is in the work they do. The table shows a tendency, not a hard line.

A template or package-priced brochure site is not what this page is about; we do not build those, and a ready-made package will fit you better and cost less. If a no-code platform or a ready-made panel is enough, we will say so as well; for a longer-term cost comparison, see our off-the-shelf or custom software total cost of ownership worksheet.

If the question is web versus mobile, we do not repeat the table here: the criteria (how often it is opened, device features, offline work) are in our guide on web app vs mobile app vs PWA. If the answer is mobile, see our mobile app development page.

What kinds of web applications do we build?

Here are some of the web-based systems in our portfolio; client names stay out because of NDAs.

• Customer and partner portals, B2B ordering. The B2B / C2C E-Commerce platforms run wholesale portals with tiered pricing, bulk orders and quote requests that route to the right rep.
• Admin and operations panels. The Fleet and Logistics Tracking platform shows route, ETA and shipment status on a live map, and on-time performance reporting to the dispatch team.
• Internal tools and finance flows. The Pre-Accounting and Invoicing platform puts invoices, expenses and cash flow in one report; payment status comes from Stripe webhooks.
• Booking and appointments. On the Booking and Reservation platform, customers book their own slot from a live availability calendar.
• Matching and marketplaces. The Talent Matching platform scores and ranks candidates against open roles.
• A product or platform that users generate. The AI App Generation platform turns a request made in chat into a working, live web application.

This is a selection; if your project looks like none of these, we can still talk. If you only have an idea or a prototype, our MVP development page covers it; if you want a system built around how you work from the start, see custom software development. If you have a web application that has aged or been left half-finished, see software consulting and modernization.

Stack and architecture: how decisions get made

Technology follows the product. Across the business systems in our portfolio we mostly used Node.js and PostgreSQL, with React and Next.js for the interfaces; Stripe handled payments, Elasticsearch ranking and search, and MQTT and WebSocket real-time device data. That is a summary of past work, not a template applied to every project. Four places that need a decision, with examples from our portfolio:

Decisions such as the split between interface and server, the sign-in method and session length depend on the product; they are among the questions in the next section. We write down the reasoning behind every technical decision, so you can always ask why a technology was chosen.

Access control, security and growth: questions to settle in the offer

This section is not a security promise but a list of questions: permissions and user data are where mistakes cost the most, and each question needs a written answer in the offer. Our principle is software that holds up under real users and real load, not a controlled demo.

API keys and server access you share are stored encrypted. If you already have a web application built with AI or ready-made tools, our 15-point production-readiness audit goes through the same areas point by point.

A real example: our own client panel

Our own client panel is an example of a web application. Every project comes with a live panel in your account: status, the offer, payment requests, the contract with digital approval, deliverables and the whole conversation, in one place.

The screenshots on the Process page show buttons to accept or decline the offer, a contract that is read to the end and then approved digitally, a payment request awaiting approval, a paid payment with an invoice link, and delivered files you download. These match the account, approval and payment items in the "Web application" column of the table above. The images are from our real panel, shown with sample data; amounts and dates are masked.

How we work

Every project follows the same four steps; the details are on the Process page. For a web application:

1. Discovery. We talk until both sides describe the same thing: who does which work in what order, and who should see what.
2. A scoped proposal. Roles, the list of screens and flows, and integrations are written down; nothing starts until you approve.
3. Building, visibly. A live project panel opens in your account; you see real progress there.
4. Review and handoff. You review what we have built, we refine it, then we hand it over.

What to bring to the first conversation

You do not need to prepare; the first conversation is a real conversation, not a form. If you have thought about these five things, it moves faster:

• Today's process. Who does the work now and with which tools? Where do time and mistakes pile up?
• Users and roles. Who will sign in, which roles will there be, and who should be able to see and change what?
• Systems and data to connect. Which software, spreadsheets or services will it exchange data with?
• A success measure. What would make you say a year from now that it worked?
• Constraints. Data regulation, internal rules, deadline pressure.

After the conversation, we settle the scope in a written proposal.

What drives the price

We do not publish figures here, because a number given before the scope is clear is only an estimate. The written proposal contains scope, timeline and cost together, and the price does not move afterwards. For a web application, the items that drive the price:

How these items show up in a written proposal, and how to compare two proposals, is in our guide on how to read a software proposal. What is binding is the written agreement signed for your engagement; this page does not replace a proposal.

Source code, infrastructure and handover

Once the project is paid in full, the delivered work is yours. What we had before your project, such as our own tools, libraries and frameworks, stays ours; the provision is written on the Terms page.

Unless you would rather handle it yourself, we provision and manage hosting, domains, storage and the deployment pipeline; if your organization needs everything under its own roof, we deploy to your cloud accounts instead. Which account holds the user data and the backups is one of the questions the offer has to settle. Access you share is stored encrypted, and when the work is done you can rotate or revoke it. If you ever want to move to another team, we help you transfer cleanly, with accounts, domains and documentation. Nothing we run for you is a reason you cannot leave.

We give a full year of direct support once you are live; we do not hand off and disappear. Support beyond that is set up separately and scaled to the project.

Who we are not a fit for

• You are looking for a packaged or template website, or only a design deliverable. We build working software; for those, a ready-made product will serve you better.
• Your only criterion is the lowest price. Weighing a job with a written scope, a price that does not move afterwards and senior engineers against a price-led quote misleads both of us.
• You only want a mobile store app. Our mobile app development page is the right place; if the answer is mobile, we say so and point you there.

Frequently asked questions

What is the difference between a web application and a website?

A website mostly informs and shows everyone the same page; in a web application, users sign in, get permissions by role and work with their own data. We do not build template or package-priced sites.

How long does a web application take and what does it cost?

Neither a duration nor a figure appears on this page, because both are estimates until the scope is clear. The role and permission structure, the number of screens and flows, integrations and data migration decide. Scope, timeline and cost are in the written proposal before work starts; once approved, the price does not change.

Should I build a mobile app or a web application?

How often users will open it, the device features it needs, offline work and the need to be in the stores decide. We build both, so we can offer a neutral recommendation; whichever the answer is, web or mobile, we will say so. The criteria are in our guide on web app vs mobile app vs PWA; for the mobile side, see mobile app development.

Can it connect to our existing systems?

Integration is a normal part of the scope. Which system, in which direction and how often is settled in the offer, depending on the interface the other system offers. In our portfolio we used Stripe for payments, MQTT and WebSocket for real-time device data, and Elasticsearch for search and ranking.

How is security handled?

Roles, record-level access, sessions, personal data and backups are each settled in writing at the offer stage; our principle is production quality from day one. API keys and access you share are stored encrypted. We make no certification or compliance claim; no software can be guaranteed to run without interruption or error.

What happens when the number of users grows?

The expected users and load are a written input to the offer, and the reasoning behind the architecture is written down. Two examples from our portfolio: a lock that prevents double bookings on the Booking platform, a webhook queue that orders payment events on the Pre-Accounting platform. They promise no figure; they show the approach.