A first version that already works

The first version has one job. It has to stop the thing that hurts most today. We do not build half of a big system, we build all of one process, so your team can use it on Monday morning.

The difference is practical. Software that handles one process from start to finish gets adopted and stays. Software that handles half of five processes sits in a browser tab while everyone goes back to the spreadsheet.

So the first question on the call is never "what do you want to build". It is "what eats the most hours today, and who loses them".

A first version pays off when the process already exists and already costs you. You do not need to invent it, you need to take it off people's hands.

• A company stuck in spreadsheetsExcel worked for a while. Now there are four copies of the same file, nobody knows which one is current, and one person spends evenings merging them.
• A company retyping data between systemsThe order arrives by email, someone retypes it into a spreadsheet, then into stock, then into the invoice. The same data four times, four chances to get it wrong.
• A company with a product ideaYou want to know whether customers will pay before you commit a full budget. A first version answers that with real users rather than a survey.
• A company burned by a previous buildThe last supplier disappeared, or delivered something nobody uses. We start with one process and show you a working version every week, so you are not buying blind a second time.

If the process is single but large and tightly tied to the rest of the company, it makes more sense to go straight to a system built around your processes rather than a first version.

We say this on the first call, before you work out a budget. There are cases where a first version wastes money and something else is the better move.

• When the process must be complete on day oneTime tracking, tax filing or any record with a legal basis does not tolerate a partial version. Either all of it works or you must not switch it on. There we point you at a finished product, such as Auresta RCP, instead of building from scratch.
• When nobody owns itIf there is no one in the company who says "this is mine and I look after it", the software will not get adopted no matter how well we write it. We settle the process owner first.
• When the process is the problem, not the missing softwareSometimes a company asks for software that would cement the mess. If two people do the same thing in two places, software will not fix that, it will only speed it up. We straighten the process first, then automate it.
• When an off-the-shelf tool is enoughIf a few hundred złoty a month buys what you need, we will say so and turn the job down. Building your own makes sense when the process is specific enough that a box product cannot handle it.

This is not politeness. We have talked several projects out of being built, and we would rather lose the job than hand over something that sits unused for a year.

We agree the scope on the free call and put it in writing before we start. Below is what usually fits into the first four to eight weeks, and what we deliberately leave out.

The deferred list does not disappear. It comes back at the review after launch, and you decide what goes into stage two.

We work in weeks. At the end of each one you get a working version at a URL you can open and click. Not screenshots and not a progress report.

1. 1We agree the shape and show a skeletonWe break the process into steps and build a clickable skeleton. By the end of the week you can see the screens and tell us where they do not match how you actually work.
2. 2Data and logins go inThe software starts saving. We load your spreadsheet data, accounts and roles arrive. From here it can be trialled with real work.
3. 3We close the processThe last steps, export, the phone view. This is the week when things nobody thought of at the start tend to surface, and that is normal.
4. 4Launch and trainingThe software goes to the server, the team gets trained, you get access to the code. From then on you work live and we stay by the phone.

A larger scope runs six or eight weeks. The rhythm stays the same, a working version every week, and payment follows in stages.

A services company, nine people, jobs arriving by email and phone. One person runs everything in a spreadsheet and retypes it into invoices later. Here is the arithmetic before and after.

People working on jobs

9

Jobs per month

approx. 180

Retyping and merging spreadsheets

6 hours a week

Hunting for what was agreed with a client

3 hours a week

Fixing mistakes caused by retyping

2 hours a week

Total recoverable

11 hours a week

First version scope

4 weeks

At eleven hours a week, a first version usually pays for itself within a few months.

This is an example, not your quote. We do the real arithmetic on the free call, on your numbers, and only then give you one fixed price in writing.

We have made them ourselves and we see them in companies arriving after a failed build. Each one costs weeks.

1. 1Scope built from a wish listWhen scope comes out of a meeting where everyone adds their own item, the first version grows to six months and nobody sees it on the way. Scope should follow one process, not a list of departments.
2. 2Building for the exception, not the ruleA company describes the hardest case from last year and the software gets built around it. Then it turns out ninety percent of jobs look nothing like that and everything is needlessly complicated.
3. 3Leaving data until the endAn import parked in the final week is the most common cause of a slipped date. Real data is always dirtier than promised, which is why we load it in week two.
4. 4No owner on the client sideIf nobody reviews the weekly version and says yes or no, the supplier makes the decisions. That always ends in software that matches the supplier's assumptions rather than the company.
5. 5Treating launch as the finishThe first fortnight after go-live is when the truth shows up. Anyone who closes the project at launch and vanishes leaves you with software nobody fixed after its first contact with reality.

A hotel in the Podkarpacie region, several dozen staff across reception, kitchen, spa and housekeeping, most of them on shifts. Attendance was kept on paper sheets and overtime was worked out by hand in Excel at month end. Mistakes and disputes happened, and people clocked in for each other.

We started with one process rather than the whole platform. The first working module is Auresta RCP, time tracking with a terminal, single-use QR or PIN login and overtime calculated without a spreadsheet. It runs on the client's own server, so employee data stays with them.

The result is easy to check. Paper attendance sheets are gone, and the head accountant runs the full records and monthly reports remotely while on childcare leave. The rest of the platform is being built in stages on a foundation that already works.

• 0paper attendance sheets
• 16absence types, Labour-Code compliant
• remotefull records and reports
• on-premisedata stays on the client's server

We wrote the whole story up as the Auresta RCP case study, including the client's reference letter.

Three pieces answering the questions we get most often before a first call.

• How much does an MVP cost →Market ranges, what pushes the price up and where people overpay.
• What you can build in 4 to 8 weeks →What realistically fits into the first month, and what does not.
• Fixed price or hourly →How to settle an IT project so it does not end in top-up invoices.