Open jobs
3
since the 6:40 sick note
Custom SaaS
Your process. As a product.
We don't build websites or stopgaps. We build a product for the one process that eats your time every day: with logins, roles, history and an export.
01
When this is worth it
02
Describe your process
The same field as on the homepage. What comes out is where our conversation starts: a proposal you can argue with.
ConceptScheduling
Crew Board
Weekly scheduling for field technicians that rebuilds itself in minutes when someone calls in sick.
How we understood your problem
Weekly scheduling lives in one person's head and a group chat. When someone is out, there is no overview: which jobs are affected, who is free, who is even qualified to take over? Every absence costs a morning on the phone.
Who it's for
- DispatcherPlans the week, assigns jobs and reacts to absences.
- Field technicianSees assigned jobs on the phone and reports illness or delays.
- OwnerReviews utilisation and overtime per crew.
Core features
- Weekly boardAll jobs per technician at a glance, reschedule by dragging.
- Report an absenceA sick note instantly marks the affected jobs as open.
- Replacement suggestionShows who is free, qualified and working nearby.
- Job details on the phoneAddress, contact and materials, without a group chat.
- Hours overviewPlanned versus worked hours per week and technician.
Deliberately left out
- No payroll: hours are exported to the existing payroll system.
- No route optimisation: with few vehicles, the dispatcher plans better than an algorithm.
- No customer portal: only worth it once internal scheduling is reliable.
What the AI does
Suggests a replacement for an absence, ranked by qualification and distance.
What the AI explicitly does not doThe AI never reassigns on its own. The dispatcher confirms every schedule change.
Integrations
- Payroll (export)
- Calendar subscription
- SMS sending
Three questions we would ask you first
-
Who may reschedule jobs: only the office, or also crew leads?
-
Which qualifications really decide who may take on a job?
-
Do all technicians have a work phone, or must this run on personal devices?
A sketch, not an offer. Generated by an AI, rendered by us.
03
Sketches we have already drawn
Hand-edited examples, not client projects. They show how we cut a problem down – and what we deliberately leave out.
04
How we work together
Three steps, each commissioned on its own. After every one you can stop and keep what has been produced so far.
Concept sprint
A fixed time box with a result you can click through.
We take your core workflow apart and put it back together as a clickable prototype. Afterwards you know what the product looks like, what it has to do – and what building it costs.
- Clickable prototype of the core workflow
- Data model, roles and permissions
- Deliberately left out: what does not belong in version one
- A binding effort estimate for the MVP
MVP
Fixed scope: one core workflow that actually runs.
We build exactly what the prototype shows – usable, not a demo. Code and rights go to you; you can carry on without us at any point.
- One core workflow, end to end
- Code and usage rights transfer to you
- Handover with source, migrations and setup instructions
- No scope that grows along the way
Operations & further development
Monthly, for as long as it serves you.
We host in Germany or the EU, keep the system current and build what daily use proves necessary. Cancellable monthly; moving it to you is prepared for, not prevented.
- Hosting in Germany or the EU
- Updates, backups, monitoring
- Further development on request, nothing built on spec
- Monthly cancellation; data and code stay yours
If your process turns into a product others need as well, we're happy to talk about licensing or a shared stake. That isn't something to decide up front.
05
What we don't do
- No websites, no shops, no newsletters.
- No maintenance of other people's systems that we didn't build.
- No consulting without building. We deliver software, not slide decks.
- No scope that grows mid-build. New ideas go into the next version, not the current one.
- No work without someone on your side who knows the process and may decide.
- No prices out of thin air. Without a concept sprint, we don't estimate.
06
The questions that come up here
Why should we trust you without references?
Not on our word. We show no client projects here – only products we built ourselves and run ourselves: FuE Stundenzettel is live in public, with its price, its trial and everything that can go wrong with it. And this site – the sketch, the budget meter, the stated limits – we built too. You can check both before you ever speak to us. This is how we build our own products; we'd build yours the same way.
Do we get a fixed price?
For the concept sprint, yes: it is a fixed package. For the build, only afterwards. A fixed price quoted before the concept exists is either guessed or padded, and you pay for the padding. After the sprint the scope is written down and the estimate is binding.
Who owns the code?
You do. On payment for the MVP, the source and the usage rights transfer to you, including database migrations and setup instructions. Third-party libraries keep their own open-source licences.
Can we stop after the concept sprint?
Yes, and that is not a special case. The prototype, the data model and the estimate are yours. Use them to run a tender, build it yourself, or drop the idea. A clean stop is better for us than a project nobody wants any more.
Where does it run in the end?
In Germany or the EU, at your own provider if you prefer. If we operate it, moving it to you stays possible at any time: ordinary technology, documented, with no mechanism that holds you in place.
How fast is this?
Faster than a route through specification documents and tendering, because we start with one core workflow instead of the full build. We'll name a figure once we've seen your process. Before that, it would be invented.
Tell us about the process.
One sentence is enough to start. We usually reply within 1–2 working days – with questions, not with an offer pulled from a drawer.