The questions that come up before a contract is signed

A B2B contract between our companies, invoiced with VAT. Its form follows the billing model: a fixed price per stage means a software development agreement; continuous development means a services agreement. It covers scope, timeline, payment terms and the transfer of economic copyright to you.

On payment for each stage, not at the end of the project. That means after every paid iteration you own what has been built, and ending the engagement doesn't leave you with nothing.

Yes, as standard, before the first detailed conversation if you need it. We will also work from your template — we have no requirements of our own beyond it being mutual.

The quote states the assumptions it rests on. If one stops holding, you get a written amendment pricing that specific change before we start work on it. There are no surprises on the invoice because there are no lines that weren't discussed.

Yes. We operate as a Polish limited liability company registered in the KRS, with NIP and REGON numbers — the full registry details are in the footer of this page.

Yours, from day one. We set them up in your name and are granted access, not the other way round. So there is never a "migration away from the vendor" — only revoking our permissions.

No. We build on widely available, open technologies, listed on the technology page. A vendor's closed engine is the most effective lock-in mechanism we know of, which is exactly why we don't have one.

By default, none of us. We work against test data; production access is named, time-limited and granted only when it is needed to diagnose a specific problem. If you have your own access policy, we work to it.

Where personal data is processed we sign a data processing agreement. When designing the system we ask which data is genuinely needed — the cheapest route to compliance is not collecting data you don't use.

That is one of the conditions we hold ourselves to. Documentation and tests are written so another team can take the system over without our involvement and without our consent. We think a vendor who can't be replaced holds too strong a position for the relationship to be fair.

We are a small team and stay that way deliberately. In practice the person from the first meeting is the one writing the code, not an account manager passing the project on. For larger scopes we agree the team by name during the workshop.

Not in the sense of handing the project to someone you've never heard of. If a project needs a skill we don't have, we say so, and either point you to someone who has it or agree their involvement openly, by name.

A shared channel and access to the staging environment from day one. We need one decision-maker on your side with roughly two hours a month — not to supervise code, but to settle questions about how your company works.

Remotely, based in Warsaw. We travel for a discovery workshop where it helps — mapping a process on a production floor usually qualifies; an office system rarely does.

Monitoring, security updates and ongoing fixes with a committed response time, billed on a retainer. The scope and the response time are agreed before launch, not after the first outage.

No. The system is yours along with its infrastructure, so your own IT team or another company can take it on. We do think some form of monitoring is essential — the worst arrangement is finding out about an outage from your customers.

We go back through the same process at a smaller scale: a call, agreeing scope, a quote. The systems we build are designed for continued development, so extending one shouldn't mean rewriting it.

When the process can be assembled from off-the-shelf tools and two integrations; when the scale doesn't justify the cost of running a custom system; or when the problem is organisational rather than technical, in which case software will only entrench it. In the short term that costs us the work. In the long term it is the only reason anyone comes back.

Yes, starting with an audit that says plainly what can be saved and what has to be rewritten. We don't commit to a takeover before the audit — without looking at the code, that commitment would be guesswork.

That is exactly the right moment. The discovery workshop exists to turn a problem into a scope — and the first conversation, where we work out whether that's what you need, is free.