Before a project starts, clients usually ask us the same questions: how do you work, how will I know what is happening, and what happens after launch? Here are our answers, with examples from the products we build and run ourselves.
Choosing how to work together
We work in three ways, and the right one depends on how clear the scope is:
- Fixed price, when the scope can be written down and agreed: a defined product with a clear list of screens and integrations.
- Time and materials, when the product will change as you learn from users, which is true for most early-stage products.
- A dedicated team, when you need engineers who join your process, your stand-ups and your codebase for a longer period.
Send us a brief and you will get a straight answer about which model fits and a rough estimate, without a sales process and without an NDA just to get a ballpark.
The first weeks
We do not start with a three-month specification. We start with the business: who uses the product, what they do today and what has to be true on launch day. Then we build something you can click early, test it with real users and move to a working version in a staging environment within the first weeks, depending on scope.
Seeing progress
You talk to the engineers who write the code, without an account manager in between. You get weekly updates and access to the task board. When something turns out harder than expected, we say so early, with the reason and the options.
Tests run on every change
Tests and automated checks run on every change, not at the end of the project. On Vitrina, our platform for cafés, a full local run of our continuous integration has 119 steps: type checks, linters, unit tests for every app, builds for two brands, a fresh database with migrations and seed data, and checks of the paths where money moves, such as the price a guest pays at checkout and the stock that a confirmed purchase adds. It takes about twenty minutes, and we run it before a change goes out.
We also add a check for each kind of mistake we have made once, so it cannot come back quietly. One example: a check that fails if a client's name is written into the code instead of coming from the configuration.
Writing things down
Decisions, trade-offs and known gaps are written next to the code, in the repository, so they do not live only in one person's head. For vporiadku, our invoicing product, we keep a status file that lists what works, what is still in testing and what is not available, and public texts may only claim what that file confirms. We think clients deserve the same honesty about their own product.
Using AI
Our engineers use AI tools every day for writing code, tests, reviews and documentation. It makes us faster. It does not replace review or tests.
Launch and after
Launch includes monitoring, error tracking and a checklist, and we stay after it: bug fixes, performance work and new features, on a monthly retainer or as needed.
Getting started
Send us a short description of what you want to build and by when. We will reply with questions, a suggested way to work and a rough estimate. Start here.