Web application

Orders sit in a spreadsheet, status updates go out by email, and clients call because they do not know where their case stands. A contact form on the website cannot carry that any more. A web application moves the whole process into one place: users log in, enter data, check their own statuses and get things done without you. The screens are only the surface; the work is done by the business logic underneath, which users never have to understand to finish their task.

We build these applications on Next.js and React: admin dashboards, client portals and SaaS platforms. Each one has login, roles, a database and integrations, and when it makes sense it also installs on a phone. Kacper Baranowski runs the project from the first call to launch, so you discuss scope, deadlines and technical decisions with the person who will then build it himself.

The first version does not have to do everything. It is better to solve one problem well than five problems halfway. We start with what delivers value from day one; features users ask for come in later stages, each quoted separately when you need it. You do not pay upfront for something you may never use.

Three situations reach us most often: a startup building the first version of its product, a company whose process has spread across spreadsheets and email, and a SaaS business that needs a portal for its customers. Each time we start with one question: which process should disappear from files, inboxes and phone calls?

We describe the two most common cases on their own pages, with scope and the questions clients ask us. An MVP for a startup means validating the idea and shipping a first version you can test with real users. A SaaS client portal is a dashboard, billing and a portal where your customers find documents, statuses and invoices on their own.

Sometimes an app is more than you need. If connecting the tools you already use would do the job, you hear it on the first call, together with a smaller scope. An app makes sense when the process is repetitive, involves many people and costs you hours of manual work every week.

• A startup with an MVP to build

  you want to test the product with users before spending on the full version

• Orders and reports circulate in spreadsheets and email, and nobody knows which version is current

• You email documents and statuses to clients who could simply look them up in a portal

• You sell software on subscription and need accounts, roles and billing

Before we give you a price, we need to know what we are pricing. We start with discovery as part of strategy and direction: who will use the app, what they need to do, what must work in the first version and what can wait. The scope, the schedule and a quote you can hold us to come out of those answers.

Then we design user flows, wireframes and a clickable prototype through design that sells. You click through it like a finished app and give feedback before we write a single line of code. The same change costs a fraction on a wireframe compared with working code, which is why coding starts only once the scope is approved.

At this stage we also define roles and permissions: who sees what, who can edit and who only approves. We list the data the app will store and the systems it has to connect to. That document stays with you: if you build the rest with someone else, they get a ready description and you never settle the same thing twice.

We build applications through our apps and PWA service on a stack we know well and that has a large community behind it. These are popular, well-documented technologies, so your own team or another vendor can take the code further later. Everything on the list below is in scope from the first version.

Security is designed together with the architecture: database-level rules (RLS) limit access to data, and every role sees only what it should. You check every change first on a separate preview address, and it reaches users only after your approval. Automated tests make sure a new feature does not break an old one.

• Architecture and UX design

  user flows, wireframes and a clickable prototype before code

• Frontend

  Next.js 16 and React, server components, SSR, a responsive interface, light and dark mode

• Backend and database

  Neon Postgres with Drizzle ORM, Server Actions, migrations and RLS

• Login and roles

  NextAuth v5, email, Google or magic link sign-in, permissions for each role

• Integrations

  Stripe for payments, Resend for email, Sentry for monitoring, webhooks

• Deployment and CI/CD

  Vercel, a preview of every change before release and automated tests

An application rarely works alone. Through integrations and automation we connect payments and subscriptions, CRM, email and invoicing tools. If your system has an API, we wire it into the app. If it does not, you hear about it before the quote, together with a workaround that will hold up.

Most business apps get by without an app store. A Progressive Web App installs straight from the browser, works offline, sends push notifications and looks like a native app on the phone. You have one codebase, no commission for Apple or Google, and updates reach users immediately, with no review process.

If you want to be in the App Store and Google Play, or you need the camera, GPS or biometrics, see our mobile app offer. It is the same technology in a native shell, so the public site, the dashboard and the phone app can stand on one foundation.

A simple dashboard or internal tool starts at PLN 15,000 net, a client portal at PLN 20,000 net. A full SaaS platform with multiple roles, payments and integrations is PLN 60,000 net and up. A simple dashboard takes 4–6 weeks, a full platform 8–16 weeks. You get a free quote with the scope written out and a schedule with stage dates within 48 hours of the call.

We give the exact figure after discovery, because the word “app” on its own is not enough to price it honestly. The biggest factors are the number of roles and views, integrations with outside systems, payments and subscriptions, and whether the app has to work offline. Larger projects are billed by stage, with a VAT invoice for each. Variants, from an MVP to a client portal, and extras with their prices are in our pricing.

Before the call, prepare a description of the process the app should handle, the roles that will use it and the tools you already rely on. A few sentences and a sample spreadsheet or email that circulates in the company today are enough. We work out the rest in discovery and write the scope down before you sign the contract.

The code, database, domain and accounts (hosting, payments, monitoring) belong to you. After launch we hand over access and documentation, so you can grow the app with us or with your own team; nothing keeps you with us except that we know this code best. Any public part is optimised for SEO, and the logged-in panel for the speed of everyday work.

When something goes wrong, we hear about it from an alert, because error monitoring runs from day one. Bugs caused by our code are fixed free of charge for 30 days from acceptance. After that you can order ongoing care: updates, backups, speed and security monitoring and new features at the pace your business changes. Small fixes happen without opening a new project; larger features are quoted separately, with scope and timeline.

Have a process you want to move out of spreadsheets and into an app? Describe it in a few sentences: what you do by hand today, who is involved and where things most often get lost. We reply by the end of the next working day and set up a short call, after which you get your quote.