Sliph: How an Excel Sheet Turned into a School App – with AI, but Not by AI

How it all started

Sliph is a locker management application for schools, and it started at my older daughter's school in Berlin.

There, the school's parents' association (Förderverein) takes care of renting out the lockers, run on a voluntary basis by parents. Over the years this had turned into quite a mess, with paper forms, several Excel lists with different versions of the data and bank transfers that someone had to reconcile by hand. That took a lot of time and was correspondingly error-prone.

At some point the parents who had been doing this were no longer willing to put in the time, and the association discussed getting rid of the lockers altogether. That would have been difficult, though, because the rental income is an important budget the association uses to fund many things at the school.

So my idea was to bring the entire process into one application, from registration to the switch into the new school year, so that the workload for the volunteers would become much smaller.

The concept

At first glance, renting out lockers is not much more than a form and a list. If you look more closely, though, there is quite a bit of domain logic behind it:

• Registration happens online, with the renter, the student, the class and the preferred locker size. Payment is by SEPA direct debit, and prices come from the tariff of the respective school year.
• Lockers are assigned through an occupancy plan by building, floor and cabinet. On top of that there are reservations with an expiry date, key handover and moves to a different locker.
• In the parent portal you sign in without a password via a one-time link. There you see all your contracts, including for several children, and can for example change your bank details.
• Contracts are cancelled at the end of the school year. The deposit is refunded or, if desired, donated to the parents' association.
• At the change of school year there is a preview of renewals, new classes and students leaving before all contracts are carried over.
• Because bank details and data of minors are processed, an audit log, a role and permission concept, a deletion concept and data subject access requests under the GDPR are needed as well.

So at the beginning it was mostly about understanding the processes. What happens when, who decides what and what must never go wrong? A locker must never be assigned twice, for example, and an IBAN must never appear anywhere in plain text. Alongside the specifications, I also built clickable mock-ups of the user interfaces.

My setup with Claude and spec-driven development

I developed Sliph with Claude Code. More important to me than the tool itself, though, was the process around it, because every change starts with a specification and not with a spontaneous prompt.

The process is the same for every feature:

1. The specification describes what the feature should do, which rules apply and which cases must not occur.
2. From it, a ticket is created with tasks, dependencies, a test strategy and a definition of done.
3. Claude implements the ticket. Project rules define architecture, conventions and security requirements so that the results stay consistent across many sessions.
4. Tests are part of every ticket, meaning unit, integration and end-to-end tests, and they are not postponed until later.
5. At the end I check whether the result matches the specification, and only then is it committed.

1. 1SpecificationRules and what must never happen
2. 2TicketTasks, test strategy, definition of done
3. 3ImplementationClaude Code, following the project rules
4. 4TestsUnit, integration, end-to-end
5. 5AcceptanceI check against the specification, only then the commit

Over time more and more of this ran on its own. Since the end of August, Claude Code has done most of the commits, even when I'm not at the computer at all. Architecture, security, domain decisions and acceptance still remain with me. Claude is a very fast developer, but it does not take responsibility for the product, and where the specification is vague, the result usually is too.

Effort and costs

Sliph was built between the first commit on 4 July 2026 and the end of October 2026, so in just under four months. Version 1.0.0 went live at the school on 15 August after 31 working days, and since then the application has been in production and is being developed further.

On my own and without AI, I estimate I would have needed at least six months full-time. As a hobby project, Sliph would probably only have been finished after years, or it would have gone live unfinished, buggy and with far fewer features, to the frustration of everyone involved and all users.

I counted commit sessions here. Because since the end of August Claude Code has mostly been committing on its own, that is not the same as my own time. That can be determined from the timestamps of my prompts from 24 August onwards and has been at least 159 hours since then.

For costs, I use a Claude Max subscription, at first the 5x plan for €100, later the 20x plan for €200 per month. Over the almost four months that adds up to roughly €600. Had I paid for the same usage through API tokens, it would have been around 10,000 US dollars by my estimate.

The figures refer to the state at the end of October 2026. Not included are around 19,000 lines of specifications and documentation in Markdown and around 17,000 lines of clickable mock-ups in HTML.

What stands out is the ratio between production and test code. Leaving out the documentation lines, there are about 1.25 lines of test code for every line of production code, and that was a deliberate decision, because I would not trust AI-generated code without this safety net. In addition, just under a third of the production code is documentation.

I'm faster at every stage, and I also write the specifications and documentation together with Claude. The biggest difference, though, is in writing the code and above all in finding and fixing bugs, which is many times faster than before.

Challenges

Sensitive data. Sliph processes bank details and student data. The IBAN is stored encrypted and only ever shown masked, every relevant action ends up in the audit log, permissions are fine-grained and there is a deletion concept. An AI doesn't suggest this level of depth on its own. It had to be in the specification and is verified through tests. In addition, a dedicated GDPR agent checks the code before every deployment to staging. It fixes smaller issues directly, and for serious GDPR violations it stops the deployment.

The licence. Sliph is meant to be free for schools and their parents' associations, but anyone offering paid hosting to third parties should need a licence. An open source licence like the AGPL can't express that, which is why I switched to the Business Source License 1.1. That had direct technical consequences, because the rich text editor in use was under the GPL and no longer fit. It had to be replaced. Today I would look at the licences of dependencies much earlier and not just shortly before the release.

The size of the codebase. When code is cheap to write, a lot of it gets written. A single file for the administration views grew to more than 5,700 lines at one point. That has no effect on runtime, but it does on maintainability, and also on how well AI agents can work with the code. Regular architecture reviews and splitting up such files are therefore a fixed part of the process.

Performance. During an analysis I found classic N+1 queries. On one overview page, the number of database queries rose to more than 370 as the amount of data grew. The tests were still green, because the result was correct. You only find problems like that if you look for them specifically.

Publication. Cleanly separating internal specifications, working documents and public documentation turned out to be more work than expected. Cross-references between files, licence notices in hundreds of files and a reproducible export each needed their own tickets.

What I've learned

• The quality of the specification determines the quality of the result. Precise requirements quickly become good code, vague ones just as quickly become vague code.
• Tests are mandatory. They are the only reliable proof that generated code does what it is supposed to do, even after the twentieth change. However, you have to specify yourself which tests are needed and what they should look like, because left to itself Claude leaves large gaps in the tests.
• Security and data protection have to be explicitly required. What isn't in the specification won't be implemented to the necessary depth.
• The architecture needs regular care. The AI optimises for the current ticket, and you have to keep an eye on the big picture yourself.
• Your own role shifts. I write less code and instead decide, review and sign off more. Experience in architecture and security becomes more important as a result, if anything.

What surprised me most is the quality of the code. Over the course of 2026 I came across fewer and fewer places where I would have said, I wouldn't do it like that, or even, this is nonsense.

Outlook

Sliph is being published as source-available software. Schools, their parents' associations and school authorities can run the application free of charge, each with its own instance per school in its own design. Anyone who wants to offer Sliph as a paid service to third parties needs a licence, and after four years each version automatically becomes available under an open source licence.

For me personally, though, the project was above all a test of the way of working. Spec-driven development with AI doesn't replace experience, it amplifies it. With clear specifications, consistent testing and someone who keeps responsibility, an application was built in just under four months that would otherwise have taken me at least half a year full-time on my own.

You can find more about Sliph at sliph.app. If you want to try the application yourself, there is a demo at demo.sliph.app, and the source code will be published on GitHub at github.com/solick/sliph.

← All posts