Our process, in-depth
Six week delivery sprint.
Week One - functional prototype. Week Six - functional production deliverable for one well defined business problem
Why this is different
You used to have to buy custom software completely blind, with no real way to see what you were actually getting.
The old way
You would describe your business in a meeting room. Someone would write a long document full of words you don't really use. You would sign it, mostly on faith.
Then you would wait — three months, six months — while people you never met built something in a language you don't speak. The first time you saw the thing you were paying for, it was already too late to change it cheaply.
How it works now
We put a working version of your idea in front of you in the first week. Not a drawing. Not a slide. Something you open on your screen, click through and use — with your process, your terms, your steps.
You can hate it on Thursday of week one, and we can change it by Friday.
That single change turns the whole thing upside down. You are no longer buying a promise. You are looking at a thing and telling us what is wrong with it — which is something every business owner already knows how to do.
The cycle
The six weeks, at a glance
- Week 101
A working prototype
You click through the whole thing, end to end, and tell us where we got it wrong.
- Weeks 2 & 302
We build it for real
We rebuild it as production software, made to run your business for years.
- Weeks 4 & 503
You use it, and change it
You and your team work with it. We change what you ask for, usually the same day.
- Week 604
It goes live, and it's yours
Switched on, on your real systems, with your real data moved across. You own all of it.
Something real lands every week. There is no week where you wait and wonder.
If that sounds too fast to be trustworthy, good — that's the right instinct. Why we can move this fast is further down, and the answer is neither magic nor corner-cutting.
Not sure yet?
You don't need a brief, a budget or a plan to talk to us. If something in your week is broken, that's enough to start.
No paperwork
The working software is the paperwork.
This is the part that makes the six weeks possible, so it's worth understanding before the rest.
We don't write a hundred-page specification. We don't ask you to sign off on a document describing software that doesn't exist yet, in language you'd need a translator for. We've watched that approach fail for years, and the reason it fails is simple: nobody can accurately describe software they have never used. Not you, not us. So the document ends up being a record of what everyone guessed in January, argued about in April, and blamed each other for in July.
Instead, the working thing is the agreement.
When your sales manager and your warehouse manager both open the same screen and click the same button, the argument about what we meant is over. There is nothing to interpret. You are not approving a paragraph; you are approving something you just used. That is a far higher standard, and it costs us less to reach it now than it used to cost to write the paragraph.
What this means in practice
No long documents to approve. You look at working software instead.
No change request forms. If something needs to change in weeks four and five, you tell us and we change it — usually that same day. The only rule is that we trade rather than pile on: something new goes in, something less important comes out.
No status meetings that exist to report on other meetings. You already saw this week's version working. That is the status report.
No ceremony you have to learn. You don't need to learn our vocabulary, our tools, or our way of running a project. That's our job, not yours.
What we do put in writing
- The price, before you commit.
- What changed each week and why, on one page.
- How to run the thing, at handover.
Those are the things you'd want to hold us to. Everything else is a working screen you can open yourself.
Week 1
The prototype: we find out whether we're right
We spend the first day or two with the people who actually do the work — not the org chart, the work. There is usually one person holding something together by hand: a spreadsheet nobody else fully understands, a folder of emails serving as a filing system, someone who stays late on the last Friday of the month. We want an hour with that person.
Then we build a prototype.
A prototype is not your software.
It's a working model of the whole solution, start to finish, built fast so that you can use it and judge it. Every step is there. It runs. You can put a real quote through it, dispatch a real technician, walk a real order from beginning to end. What it is not is something you should run your company on — and we'll say so plainly at the time.
The purpose of week one is a single question: did we understand your problem, and does this shape of solution actually solve it? That's a guess until somebody uses it. So you use it, and you tell us where the guess was wrong — and there is always something. Two steps are backwards. There's a customer type we didn't know about. The thing we assumed was hard is trivial, and the thing we assumed was trivial is where your whole month goes.
We change it, that week, while you watch. By Friday we're usually on the third or fourth version, and it's close.
What you do
Give us a few hours and be blunt.
What you get
A prototype you have personally used, and an answer to the question of whether this is worth building for real. Both are yours to keep, whatever you decide next.
Weeks 2 & 3
We build it for real
Now we take the prototype apart and rebuild it as production software.
That phrase deserves an explanation, because it's where your money goes and it's invisible from the outside. The prototype and the finished software can look almost identical on screen. They are not remotely the same thing underneath.
To put something in front of you in five days, we deliberately skip everything that protects you. Production ready means putting all of it back.
What goes back in
It handles real volume. The prototype is happy with fifty records. Yours will have fifty thousand, and it needs to stay fast on the worst Monday of the year.
It knows who is allowed to do what. Proper logins for each person. The warehouse sees what the warehouse should see, and no more. Nobody can change a price who shouldn't be changing prices.
It holds your real data properly. Migrated from wherever it lives now — the old system, the exports, the spreadsheet — and structured so it stays correct as it grows.
It does not lose anything. Backups, taken automatically, and tested by actually restoring them. If something goes wrong at four in the afternoon, you go back to four o'clock, not to last month.
It behaves when people make mistakes. Someone will type a date wrong, click submit twice, upload the wrong file, close the laptop mid-way. Every one of those has to end somewhere sensible instead of somewhere broken.
It's checked automatically, every time we touch it. We write tests — small automatic checks that run on every change and shout if something that used to work has stopped working. This is the single biggest reason software is still fixable two years later, and the single most common thing cut by people quoting you a cheaper price.
It talks to the systems you already run, so nobody retypes the same number into two places.
It keeps a record. Who changed what, and when. The question “who approved this discount in March” gets an answer.
It tells us when it breaks. Monitoring, so we know before you phone us.
It lives somewhere real, in the EU, on infrastructure that belongs to you and that you could move tomorrow.
Where AI does work inside the software — reading incoming email, drafting a reply, sorting a queue, flagging the exception — this is also where it stops being a clever demonstration and becomes something dependable, watched, and possible to overrule.
None of week one is wasted. The prototype has already done the job a hundred-page specification was supposed to do, and done it better: everybody has seen the same thing, and nobody is imagining a different product. It's the blueprint we build against.
What you do
Get us your real data and access to the systems it has to talk to, early. This is the one thing that can hold up everything else.
What you get
By the end of week two, the thing you used in week one, rebuilt properly and running on your own live information. By the end of week three, it's finished software with all of the above in place, ready for your team to get their hands on.
Weeks 4 & 5
You use it, and you change your mind
Your team now works with it properly — real orders, real customers, real numbers — on a system that is set up and running for them, though not yet switched over as the one your business depends on.
And within about two days, someone will want something different. A field we didn't think of. A step that made sense in a meeting and makes no sense at eight in the morning in a warehouse. Someone will say “actually, could it also…”
This is not a problem. This is the process.
You could not have known these things earlier, because you had never used it before. Nobody can accurately specify software they have not yet lived with — that's exactly why we stopped asking people to. Anyone who tells you a change at this stage is your fault has either never built software, or intends to charge you for every one of them later.
So these two weeks exist for this. Not as a grudging concession — as a planned part of the six weeks.
And you'll see the changes the same day. We deploy continuously through these two weeks, often several times a day. You mention something at ten in the morning and there's a fair chance you're looking at it after lunch. There is no release cycle, no waiting for the next version, no list of your requests sitting in a queue somewhere for a month.
If your customers touch it — booking, ordering, uploading, asking questions — then what they do goes in here too, even secondhand, and it's usually the most valuable information in the whole project. Real use tells you things opinions cannot: where people slow down, which screen everyone avoids, which step quietly gets skipped.
One rule keeps this sane: we trade rather than pile on. If something new goes in, something less important comes out, and we'll be straight with you about which is worth more. This is how six weeks stays six weeks.
What you do
Let your people be honest, including the one who says they preferred the spreadsheet. Tell us what your customers said.
What you get
Changes shipped daily, and software measurably faster to use at the end of week five than at the start of week four.
Week 6
It goes live, and it's yours
The final week is the switch-on.
We deploy it to your real working infrastructure — the live systems your business actually runs on — with your real data moved across and everything connected. It stops being a thing your team is trying and becomes the thing your team uses. We're watching closely all week, because the first days of live running are when the last surprises appear.
We also step back on purpose. Your team runs it without us over their shoulder. We train the person who owns it. We hand over everything: the software, the code, the accounts, and a short written guide in the same plain language as the rest of this page. It belongs to you — not to us, and not to a platform you cannot leave.
What you get
A working piece of software, live and in daily use, built for exactly how your company works, that you own outright.
The honest answer
Why we can move this fast
You should be suspicious of this. Working software in the first week, the whole thing in six — either something is being cut, or something is genuinely different. It's the second one, and here is exactly what it is.
- Nucleus
We're not starting from an empty page.
Every business application needs the same unglamorous parts underneath it. Logins. Permissions. A record of who changed what and when. Notifications. Reports. Search. Sending files out and taking files in. These are the same in a clinic as they are in a warehouse, and they take weeks to build properly.
So we built them once, and have been sharpening them on every project since. We call it Nucleus — our own library of finished parts, running in production across our clients' systems today. We install them. We don't rebuild them at your expense.
It's worth being precise about what this is not. Nobody expects a builder to fire their own bricks or cut their own screws — you'd treat it as a warning sign if they insisted on it. The house is still yours, laid out exactly how you want to live in it. Nucleus is the bricks. What we build in week one is the part that is genuinely about your business, and that part is built for you and nobody else.
AI writes a great deal of the code now. The valuable question is who checks it.
Everyone has access to AI that writes software. That is not an advantage anyone can claim anymore, and any agency telling you it is theirs alone is selling you something. What is not evenly distributed is what happens next.
We spent the last year building the layer around it: our own agents that hold every piece of work up against what it was supposed to do, review it, and reject it when it doesn't measure up. The same standard on every project, every time, without a person getting tired at five o'clock on a Friday. Nothing reaches you because it looked right — it reaches you because it was checked.
That is precisely why we're comfortable moving fast. Speed without checking is how you end up with software that works beautifully in the demonstration and falls apart in month two.
The people who sell it are the people who build it.
There is no account manager, no handover to a team you have never met, no part of it quietly sent somewhere cheaper. You deal with the two senior people who run this company, from the first phone call to the handover. What we hear in week one, we build ourselves. Nothing is lost in translation, because there is no translation.
- Sentinel
When there is AI inside your software, we can see everything it did.
This is the part that should worry you about AI, so we built for it. Sentinel is our own monitoring layer: it records every decision the AI made, what it was asked, what it answered, and what it cost. When you ask “why did it do that,” you get an answer rather than a shrug. Nothing about your business runs inside a box nobody can open.
And years of watching the same problem wear different clothes.
The quoting bottleneck at an electronics distributor is the same shape as the intake bottleneck at a clinic. We have usually solved your problem before, in an industry that looks nothing like yours. That is most of why week one is possible at all — we're not discovering the pattern, we're recognising it.
Our side of it
Why we stand behind the plan
Because it isn't a promise about the future. It's a description of what we already do, repeatedly, and we've arranged things so that we carry the risk rather than you.
- The price is fixed in writing after week one, once we have both seen the thing working.
- You own everything built, at every stage, including if you stop early.
- There is no cycle you are obliged to buy, and nothing to escape from if you would rather not.
If we're wrong about your problem, you find out in week one — while it's cheap, and while you still have all your options.
A fair question
Wondering whether your problem is the right size for one cycle? That's what we get asked most, and we'll answer it straight — including when the answer is no.
Conditions
The seven rules that make six weeks possible
Six weeks is not a sales figure. It's what this process produces when certain things hold true, and it stops working when they don't.
So we name them up front rather than discovering them in week four. None of these are us being difficult. Each one exists because we've watched a project go wrong without it.
One problem, not one department.
A cycle solves one workflow that hurts — quoting, dispatch, intake, month-end. Not “our operations.” If you bring us three problems, we'll help you choose the most expensive one and the other two wait for the next cycle. Two problems in six weeks means two half-solved problems, and half-solved software gets abandoned.
The date does not move. The scope does.
Six weeks means six weeks. When something takes longer than expected — and something always does — we don't extend the deadline, we adjust what goes in. A fixed end date is the only thing that reliably forces the honest conversation about what actually matters. Movable deadlines are how a six-week project becomes a nine-month one, one reasonable week at a time.
One person decides, the same day.
Not a committee, not a monthly steering meeting. One named person on your side with the authority to say yes or no, reachable within a working day. At this speed, a decision that takes a week costs you a sixth of the project. This is the single most common reason a cycle underdelivers, and it has nothing to do with software.
Real access by week two — the data and the people.
Your actual data, exports and all, plus an hour each with the people who do the work. Not the polished version. The spreadsheet with the manual corrections in it, and the person who knows why they're there. Every company has workarounds nobody is proud of; they're usually where the money is. Without this by week two, weeks two and three cannot happen, and the date in rule two is the one thing that will move.
Something in means something out.
From week four onward you'll want changes, and you should have them. But the cycle is full. Anything new displaces something already planned, and we'll tell you plainly which we think is worth more. We don't quietly absorb additions and we don't quietly drop things to make room — you see the trade and you make the call.
Changes close at the end of week five.
Week six is the go-live: deploying to your real systems, moving your data across, training, handover. Changing the software while switching it on is how switch-ons go wrong. If we're still building on the Wednesday of week six, you get a rushed launch and a handover nobody on your side is confident about — and software nobody confidently owns quietly dies four months later. The last week is protected, without exception.
A person approves anything that touches a customer or your money.
Where AI does work inside your software — reading, drafting, sorting, deciding — a human being sees it and can overrule it before it reaches a customer, an invoice, or a bank. We won't build you something that acts on your behalf with nobody able to check it, even if you ask us to. This is the one rule that is ours rather than yours.
If we cannot agree on these before we start, we'll tell you. It's the most common reason we turn work down, and both of us are better off hearing it in the first conversation than in week five.
In practice
What this actually looks like
Some of the shapes this takes. Yours will be different, but these will feel familiar.
The quote that used to take two days
Before
A customer emails asking for twelve items and a delivery date. Someone retypes it into a spreadsheet, checks stock in a second system, works out the pricing, and replies on Thursday.
After
The email arrives, the system reads it, checks stock and pricing, and puts a finished quote in front of your salesperson to approve or adjust. They send it in four minutes. Nothing goes out without a human saying yes.
The maintenance requests arriving from five directions
Before
Phone, email, WhatsApp, a note left on someone's desk. Dispatch runs on memory, and something always slips.
After
Every request lands in one queue, sorted by urgency, assigned to the right technician, on their phone with the history of that building attached. The client asking “what happened to my request” gets an answer in three seconds.
The reception desk drowning in the same nine questions
Before
A clinic where the phone rings all day: opening hours, do you take this insurance, can I move my appointment.
After
The routine ones are answered instantly, day or night, in Croatian and English; anything needing a person goes to a person with the context already gathered. Reception gets its day back.
The Monday morning paper pile
Before
Checks, readings, inspections and deliveries recorded on paper in the field, then typed into a computer on Monday by someone who would rather be doing anything else.
After
It's captured on a phone where it happens, and anything out of range is flagged the same hour instead of the following week.
The month-end that eats three days
Before
Numbers pulled from three systems that don't speak to each other, reconciled by hand, in a workbook one person understands and nobody else can maintain.
After
It assembles itself, the differences are highlighted for a human to judge, and month-end takes an afternoon.
The common thread: none of these replace your existing systems. They sit around them and fix the part where a person is doing work a machine should be doing.
Sound familiar?
If one of those is your Monday morning, tell us which one. That's usually all we need to say something useful back.
Afterwards
And then you decide what the next six weeks are for
The cycle is the unit. Not the contract, not the roadmap — the cycle.
At the end of week six we sit down and look at what we both now know, which is considerably more than we knew six weeks ago. From there, there are only ever four honest answers.
Stop.
It does the job. Take it and go. Some of the best outcomes we've had ended here, and we'd rather you come back in a year because it worked than stay because you were tied in.
Go deeper on the same thing.
Six weeks got the core working and being used. Another six could handle the three cases you set aside, open it to your customers, or let the AI take on the next slice of the work now that you've watched it handle the first.
Point it at a different problem.
This happens more than anything else. Once one part of the business runs properly, the next bottleneck becomes obvious — and it is frequently not the one you would have picked in January.
Keep it running quietly.
No new work, just looking after it. Same as a vehicle. We'll tell you what that costs before you commit, not after.
Each cycle is decided on its own, priced on its own, and started only if it's worth it. There is no long contract to escape and no roadmap you have to keep funding to justify the last decision. If a cycle is not obviously worth the next one, we would rather tell you than sell you.
Before you ask
What we need from you
Rules three and four above are the whole of it, and they cost less time than people expect: two to three hours a week from one person. Real time, not answered between meetings.
That is the entire demand on your side. Everything else is ours.
What six weeks is not
It's not a replacement for your whole system. We don't rip out an ERP in six weeks. We build the piece around it that makes it usable.
It's not unlimited changes. Weeks four and five are for changes. Beyond that we trade one thing for another, or it becomes the next cycle.
It's not software that runs itself with nobody watching. Where we use AI, a person can always see what it did and overrule it.
It's not a commitment to a second cycle. Every cycle ends with you free to walk away owning everything built so far.
How it starts
One conversation.
Around forty-five minutes, by phone or video, or in person if at all possible.
You describe the thing that isn't working. We ask questions. At the end we tell you honestly whether we think we can help — and if we can't, we'll say so and point you somewhere better if we know of one.
No commitment, no cost, and nobody will chase you afterwards.
Or write to office@upheave.tech.
