Web applications and panels for business in Gdańsk

The spreadsheet grows, people keep adding columns to it, and the report still has to be assembled by hand. An off-the-shelf system does most of what you need — but the missing part is usually exactly where you make your money, and that is the part you cannot change.

At some point the company starts working around the system instead of the other way round. An application written for your process reverses that dependency: the tool adapts to how you actually work. We work from Gdańsk, on site across the Tricity, remotely across Poland.

Simplified illustration of a panel: a record card, a permissions matrix and integrations. An illustration, not a screenshot from a deployment.

What the scope covers

  • Process analysis before any design — what can be removed before anything is automated
  • Architecture and data model built for your process, not for a universal template
  • A backend carrying the business logic and a documented API
  • An interface that behaves the same on a computer, a tablet and a phone
  • Roles and permissions described by what people actually do
  • Integrations with the systems you already run — without interrupting daily work
  • Separated dev, stage and production environments, releases automated
  • Hosting, SSL certificate, backups and monitoring — configured and running
  • The technical side of GDPR: change log, data minimisation, isolation of key data
  • Documentation, handover of every access credential and full ownership of the code
  • Free bug fixes within the agreed scope — a clause in the contract, not a promise

Hosting, the SSL certificate, backups and the technical side of GDPR duties are configured as part of the implementation — they belong to the agreed price, not to a separate line item. Ongoing care of a running system, meaning updates, monitoring and support, is a separate subscription, quoted at handover.

How we work

  1. A conversation about the process

    We take apart how the company works today: who enters data, where the bottlenecks form, and which steps can simply be removed instead of automated.

    What we need from you Access to the people who actually work inside the process, not only to its description.

  2. Scope and a fixed price

    We write down what will be built and what deliberately stays outside the scope. For that scope the price is fixed and does not move during the work.

    What we need from you A decision on what is essential at launch and what can wait for a second stage.

  3. Prototype

    A clickable prototype of the key screens comes before production code. Changing the layout at this point costs a conversation, not a rewrite.

    What we need from you Feedback on the prototype from the people who will use it daily.

  4. Delivery in stages

    We work in modules: every finished piece goes to the test environment and can be seen working, instead of waiting for the whole.

    What we need from you Test data and a contact for the administrator of the system we integrate with.

  5. Handover and care

    Documentation, training, handover of the repository and of every access credential. Ongoing care is a separate, voluntary agreement — the system is yours regardless of it.

    What we need from you The name of the person who will take the system over on your side.

What three years cost: a custom build or a subscription

Compare the cumulative cost of two roads over 36 months. You enter every number yourself.

Setup, migration, configuration. If the alternative costs nothing at the start, enter 0.

Fill in every field — without them there is nothing to calculate. We substitute no default values, because each of them would be our assumption rather than yours.

This is arithmetic from the assumptions you entered, not our forecast. Every number in the result comes from the fields above — there are no market averages and no estimates of ours in it.

Open the full calculator →

Common questions

How long does a web application take?

It depends on the scope — usually from a few weeks to a few months. The actual schedule is produced together with the scope and the fixed price, and you get it in writing before work starts. Naming a number earlier would be guessing.

Do we own the code?

Yes. The repository, the architecture and every access credential move to your side at handover. There is no licence on an engine of ours and no fee for continuing to use your own system.

What if we want to develop the system with somebody else?

That is accounted for. Documentation, a readable architecture and standard technologies exist partly so that a handover is possible. We do not build dependence on us into the offer.

Will you integrate with the system we already have?

Usually yes, and it is most often the most important part of the project. The integration is built without interrupting daily work: first on the test environment, only then on production. If the system exposes no API, we look at other ways of exchanging data and say plainly when one of them is fragile.

Who pays for hosting?

Configuring hosting, the SSL certificate, backups and monitoring is part of the implementation scope and not a separate line item. Ongoing care of the running system — updates, monitoring, support — is a separate subscription that we quote at handover.

Can we start with a small scope?

Yes, and it usually works out cheaper. The first stage covers a single process, the one that hurts most; the rest is added once the first one runs. The architecture assumes from the start that more will come.

What about GDPR?

On the technical side it is part of the scope: separated permissions, isolation of key data, a change log and minimisation of what is collected at all. We do not draft legal documents — policies, processing agreements, records of processing activities. That is a lawyer's job, and we say so rather than implying that a deployment covers everything.

Let us talk about your project

Pick a time for a call or leave your number — we call back during working hours.