You send a message describing your project, and within an hour someone replies. This article covers everything that happens next when working with a software house like ours: who does what at each stage, which decisions are on your side, what you get at the end and where projects really lose time.
Every project, from a landing page to a system with an admin panel and integrations, goes through the same seven stages. What differs is how long they take, not their order. The short version is on the How we work page; here we lay it out with the details there's no room for on that page.
You describe what you want built, and we come back with questions, a price range and a preliminary scope.
You get an account where you can see the schedule, files, billing and tickets.
The layout and flow of the key screens, before the first line of code is written.
Work on staging and in a shared repository, with progress reports.
A pre-launch checklist and spare time for corrections included in the price.
Launch on the agreed date, with the repository, documentation and access on your side.
Monitoring and tickets in the same panel we ran the project in.
The first message: what to write to get a specific answer
The first message doesn't have to be a specification. It's enough if it answers three questions we'd ask in our reply anyway: what needs to be built, who it's for, and what happens if you don't build it. The last question isn't meant to be awkward. It shows whether we're talking about a tool that will save your team hours of work, a website that should bring in enquiries, or an idea that first needs testing on the market. That answer decides whether we propose a quick version or a polished product.
Compare two messages about the same project:
We need an order panel. How much does it cost?
We have a brick-and-mortar shop and take wholesale orders by email. Three people copy them into a spreadsheet and into our invoicing program. We want a panel where a wholesale customer places the order themselves and we see it straight away with its status. We issue invoices in one program and want the data to end up there. Deadline: before the autumn season.
To the first message we'll reply with questions; to the second, with a price range and a list of things to clarify. Both are fine; the second simply saves one round of messages. If you don't know how to describe something, write it the way you'd explain it to a friend, without jargon. Turning that into a technical scope is our job.
We reply within an hour, and the reply comes from the person who will write the code, not from a salesperson who passes your questions on. Day to day we communicate on Discord, because it makes it easy to swap screenshots and short questions without long email threads, but the first contact can come through any channel, for example the contact form.
The quote: a range first, then a specific figure
We don't have a fixed price list or packages, because two projects with the same name, say "online store", can differ in scope so much that a shared price would say nothing. We only publish "from" prices, which show the lower bound for each type of project: Landing Page from PLN 499, Company Website from PLN 1,199, Panels & Dashboards from PLN 699, Web Platforms from PLN 899, Online Stores & E-commerce from PLN 1,699, Mobile Apps from PLN 749, Desktop Apps from PLN 999, Integrations & Automation from PLN 299.
The quote has two steps. For a general outline of the project we give a range, so it's clear straight away whether we're in the same ballpark as your budget. We give a specific figure only once the scope, deadline and requirements are agreed, because only then is it clear exactly what we're pricing. Both steps are free, as is advice at the stage when you don't yet know what you need.
The quote you receive contains a list of features described so that you can check whether they were delivered, the deadline, the payment schedule and a list of things outside the scope. That last list matters as much as the first: if copy for the website, photos or fees for third-party services are on your side, you should know that before signing the contract, not halfway through the project.
At this stage we sometimes say "no", or propose something different from what you asked for. If the deadline is too short for the full scope, we propose a smaller first version that will make it, and the rest in a later stage. If the conversation shows that the problem can be solved with an off-the-shelf tool, we say so plainly. We'd rather say "no" than promise something we won't deliver. No pressure for a quick decision works both ways: you have time to compare our offer with others.
Contract, NDA and payment schedule
If the project involves something you don't want to share without protection, we sign an NDA on request before we exchange details. That usually covers product ideas, customer data in sample files and documentation for the internal systems we're meant to integrate with.
The contract puts in one place what we agreed during the quote: scope, deadline, price and how acceptance works. We most often split payment into three equal parts, 33/33/33, tied to project stages. That way neither side carries all the risk up front: you don't pay everything before seeing results, and we don't work for months without being paid. We write the payment points into the contract together with what has to be ready for each part to fall due.
The price includes a buffer for fixes equal to 15% of the project time. It isn't an extra charged later, but time planned in advance for corrections that come up during testing and in the first period after launch. There's more on what it covers in the section on testing.
The contract also sets out what happens to the code. When the project is finished, you receive full rights to the code and documentation that lets another team take it over. We write this down from the start, because it's a decision that matters a few years from now, when you're developing the system further, not on the day of signing.
Onboarding in the client panel
Once the contract is signed, you get an account in the client panel. It's the place where the project is visible to both sides from day one, with real data, not as a promise that "we'll show you everything at the end".
In the panel you'll find several views, each answering a different question:
- Dashboard - the status of each stage, recent events and what's waiting for your decision.
- My projects - every engagement with its schedule, milestones and links to staging and the repository.
- News - changes and things to confirm, gathered in one place instead of scattered across your inbox.
- Billing - invoices, payments and the project budget in one view.
- Support - tickets and questions that stay attached to the project, with their full history.
- Settings - account details, access for people on your team and notifications.
Onboarding is also the point where you have the most to do. We need access that can't be generated on your behalf: to the domain, to existing hosting, to accounts with the third-party services the project has to connect to. We also need materials: the logo, visual identity, copy, photos, sample data. Each of these that arrives late pushes back everything that depends on it.
The most important organisational decision at this stage is naming one person on your side who signs off the prototype and accepts each stage. They can consult whoever they like, but the final "yes" should come from one place. A project where three people give conflicting comments on the same screen stands still until they agree on a version among themselves.
Prototyping the interface: the cheapest moment to change your mind
Before any code is written, you see the layout and flow of the key screens as wireframes. These are simplified sketches without colours or final typography yet. We discuss where a button sits, in what order the sections are read and how many steps separate the user from their goal.
What we prototype depends on the type of project:
| Type of project | What the prototype focuses on |
|---|---|
| Company website | Layout, content hierarchy and the path to contact, before the visual design starts |
| Panel and dashboard | Navigation, tables and data views mapped out the way they'll be used day to day |
| Online store | Product page, cart and checkout, with the order of steps settled up front |
| Mobile app | Phone layouts designed in parallel, not bolted on at the end |
This stage exists for one reason: a change on a sketch costs hours, while the same change in finished code can cost weeks. Moving a section on a wireframe takes a few minutes. Moving it after the components, data and mobile version have been built underneath it means rebuilding several layers at once.
When reviewing the prototype, don't judge it like a finished website. Ask yourself different questions: does every screen show data you actually have, does every path end with a specific action, what does the user see when a list is empty or a form returns an error? Note down comments about colours and photos for later, because they'll come back at the visual design and build stage.
Signing off the prototype means freezing the layout. That doesn't mean nothing can change any more, but every layout change after that point is treated as a change in scope, with its impact on the deadline and price spelled out. That's why it's better to spend an extra day on the prototype than to sign it off in a hurry.
Building the software: staging and a repository from day one
The build happens on staging, a test version of the project at a separate address, and in a shared repository. You have access to both from the start, not only at acceptance. At any moment you can open staging and see how the project looks today, or look into the repository and check what has changed since yesterday.
The product grows in phases, and it helps to know what they look like so you don't report as bugs things that are deliberately unfinished. A typical rhythm for a project with an admin panel looks like this:
Routing, data model and application structure. An empty but working framework.
Views laid out according to the approved prototype, with temporary data and copy.
The interface starts showing what it will show in production.
Connections to external systems, charts, error handling and polished mobile versions.
The number and length of the phases depend on the scope. A small landing page can go through them in a few days; a system with several integrations needs more time for each. What stays constant is the order, and the fact that you see each phase on staging as it's being built, with the desktop and mobile versions growing in parallel.
You get progress reports without asking: a short summary of what's done, what's in progress and whether anything is waiting for your decision. You don't have to ask where things stand. Quick questions along the way, for example about the wording of an error message or the order of fields in a form, we ask on Discord, and matters that should stay in the project history go into the panel.
We set the pace to suit you. If you need a working version as soon as possible to test the idea on users, we build an MVP and deliberately postpone polishing the details. If the project has to look and work without compromises from day one, we plan more time for polish. Both paths are honest, as long as it's clear from the start which one we're taking.
Changes during the project: a fix or new scope
In almost every project, an idea that wasn't in the scope comes up during the build. That's normal, because only a working version on staging shows things you can't see on a sketch. What matters is that both sides understand the same way when a change is a fix and when it's new scope.
A fix is when something works differently from what we agreed, or needs a small correction within what already exists: a typo, a misaligned gap, a form field that should be required, a message that reads unclearly. A change in scope is something new, or a rework of something already approved: an additional view, a new integration, a layout change after the prototype was signed off, a new user role with its own permissions.
| Request | Type | What happens |
|---|---|---|
| A button submits the form without a required field | Fix | We fix it within the project |
| The error message is hard to understand | Fix | We change the wording within the project |
| A table should have an extra column with data already in the database | Depends on scale | Usually fits within the buffer for fixes |
| A new management report with its own filters | Change in scope | We describe the impact on deadline and price, you decide |
| Integration with a second invoicing program | Change in scope | A separate quote before work starts |
With a change in scope, we don't start work until you've received a description of its impact on the deadline and price. You can accept it, move it to a later stage after launch, or drop it. That way there's no surprise at the end of the project in the form of an invoice for things whose cost nobody discussed.
The buffer for fixes, equal to 15% of the project time, is there so that the line between a fix and a change doesn't become a point of dispute over every small thing. Small things that come up in practice we do without counting minutes, and the conversation about scope only starts with changes that genuinely affect the schedule.
Testing and the buffer for fixes
Before deployment, the project goes through a checklist we've built up over years so as not to make the same mistake twice. It covers six areas:
| Area | What we check |
|---|---|
| Critical paths | Sign-up, payment, form submission, clicked through by hand from start to finish |
| Responsiveness | Widths from 360 px up, with real content rather than placeholder text |
| Performance | Core Web Vitals measured on the production build, not the development version |
| Accessibility | Contrast, keyboard navigation, meaningful labels on fields and buttons |
| Error states | What the user sees when something goes wrong: no network, an empty list, invalid data |
| Security | Data validation, permissions and protection of forms against abuse |
For performance, the reference points are the thresholds Google publishes for Core Web Vitals: time to render the largest element (LCP) under 2.5 seconds, response to interaction (INP) under 200 milliseconds and layout shift (CLS) under 0.1. We measure them on the production build, because the development version behaves differently and its results prove nothing.
In parallel with our tests, you check the project on staging from your own perspective. You don't need to repeat our checklist. The most valuable scenarios are the ones only you know: a real customer with an unusual order, data that looks different in your industry than in the examples, the phone your team actually works on. You report comments in the panel, where each one has its own status and history.
After testing, there's the buffer for fixes included in the price: 15% of the project time. It covers corrections that come up at acceptance and in the first period after launch, when the project meets real users. We don't send a separate invoice for every typo and every misaligned element.
Deployment and code handover
We set the deployment date together, so that it doesn't catch your users or your team by surprise. We prefer to deploy in the middle of a working day, when both sides are available and any problem can be solved immediately, rather than on a Friday evening when everyone is already offline. If the project replaces an existing system or website, we agree beforehand what happens to the old URLs, data and user accounts.
Launch day has a few technical details worth knowing in advance. Changing a domain's DNS records doesn't take effect for all users in the same minute, because intermediate servers remember the previous values for the time set in the TTL parameter, which is why that time is lowered ahead of the switch. If the new website changes page URLs, the old URLs get 301 redirects to their new equivalents, so you don't lose links from search engines and partners. If email is sent from the domain, we check that the change doesn't break its records.
After launch you receive everything that makes up the project:
- Repository - with the full change history, transferred to your account.
- Documentation - how to run the project, how to deploy it and where each part lives.
- Access - server, domain and third-party services registered in your name, not ours.
- A live walkthrough - a call where we walk your team through the project and answer questions.
The code is yours and isn't held hostage by our company. You have full rights to it, and the documentation is written so that another team can take it over without calling us. If a year from now you decide that someone else, or your own developer, will take development forward, you don't need to ask us for anything.
This approach has a practical effect on us as well: since we assume someone else may read the code, we write it so it can be read. A repository that the client could see throughout the project has no corners nobody was meant to look into.
Post-launch support and monitoring
Launch doesn't end the collaboration. After deployment we monitor the project's availability and response time, usually for 90 days at no extra cost. If something stops working, we usually know before the first user reports it.
Tickets after launch go into the same panel we ran the project in. Nobody starts the conversation from scratch or has to reconstruct the context, because the whole history of decisions, tests and fixes is in one place. Asking about anything to do with the project costs nothing.
After the monitoring period, further support depends on the project. A company website whose content rarely changes needs different support from an online store or an admin panel the team uses every day. The scope of support, response times and any availability terms are agreed individually in the contract, in proportion to how much the business depends on the system working.
The first weeks after launch are also a good time to collect a list of things for the next stage. The scope changes we postponed during the build, together with observations from real use, usually give more concrete material for planning than any conversation before launch.
Where working with a software house really slows down
Most delays don't come from the code turning out harder than expected. They come from things waiting for a decision or material, with nobody noticing for several days that the whole stage has stalled. We describe them openly, because some are on our side and some on yours, and both are easier to control when you know about them up front.
| Blocker | Effect | How to avoid it |
|---|---|---|
| No single decision-maker | Conflicting comments on the same screen, work going round in circles | Name the approving person during onboarding |
| Copy and photos arrive at the end | Screens wait on placeholders, testing with real content slips | Put the materials deadline in the schedule like any other stage |
| Access to third-party services | The integration is ready on our side but can't be switched on | Create the accounts and collect the keys during onboarding |
| Verification with the payment provider | The store is ready, payments are inactive | Start account verification with the provider at the beginning of the project, because it runs on their side |
| Layout change after prototype sign-off | Several layers rebuilt, deadline moved | Spend more time on the prototype, report changes as separate scope |
| Comments scattered across email, chat and phone | Requests get lost or are done twice | Report everything that should stay in the history in the panel |
On our side, the risk that can't be ruled out at the quoting stage is an integration with a system whose documentation doesn't match reality. When that comes to light, we say straight away what it means for the deadline, instead of trying to make up for it quietly at the expense of testing. A progress report that mentions a problem is worth more than one where everything always goes according to plan.
The simplest protection against most of these blockers is a response deadline written next to every stage that needs your decision. A late sign-off rarely moves the launch by exactly as many days as it was late, because once it arrives the work still has to regain its slot in the schedule and get back into context. The dashboard in the client panel shows the things waiting for your decision precisely so that they don't sit unnoticed among other messages.
If you have a project you'd like to take through these stages, write to us via the contact form. You'll hear back from the person who will build it, with questions and a price range, and you'll find the starting prices for each type of project on the offer page.
