We were recently contacted by a client — a lab at Tel Aviv University — about an issue they found in a project we delivered almost a year ago: a problem in one of the graphs in a specific breakdown.

The system is a meta-study web application that aggregates results from hundreds of experiments and studies. It lets researchers in the field of unconscious processing slice and dice the data, run queries, visually explore trends, and download the related figures. We took great pride in modeling highly complex data and serving fast, on-demand visualizations — both in this project and in its sister project in the field of theories of consciousness.

But underneath a smooth UI lies a very intricate set of data structures and logic, crafted through hours of discussion with the client. Coming back to such a project after a long time is tricky: you need to relearn the domain, the data model, and the terminology, and verify whether the reported issue is actually a bug or simply "working as designed." If you're not careful, this can turn into a time sink — and you don't want to overbill a client for what is essentially your own re-learning. Fortunately, we tackled the issue quickly, because this is a well-maintained project.

It got us thinking: what really makes a project maintainable? And how do we bring the same discipline we use in startup-land into agency work?

Maintainable, readable, elegant code

Not AI-generated slop. The best code is the code you don't need to write. AI assistants are great — we use them daily — but we own the code. You can solve a problem by dumping thousands of AI-generated lines into a codebase, but you won't be able to debug or maintain it later.

Documentation — for both humans and agents

How to run the project. Setup steps. Architecture, data model, and major design decisions. Good documentation is an investment in your future self (and your future AI helper).

Deep, correct data modeling

Data modeling is still king. And the only way to model data well is to dive deep into the client's domain until you truly understand it.

Treat change as inevitable

Every project will need maintenance. Requirements evolve, the world shifts, and user expectations grow. We design and write code assuming that someone — maybe us, maybe someone else — will have to modify it later.

If you need help turning a business initiative into working, maintainable software, reach out.