SilentPixel does two kinds of work: products of our own, and software for businesses. People sometimes assume the first is a side project competing with the second for attention. In practice it is the best preparation for the second that we know of.
Our own product, the E-Bike Battery Passport, is live at battery.silentpixel.net. It gives every e-bike battery one verified record, shared by the companies that make, sell, repair and recycle it. Building and running it ourselves has changed how we approach every other project, in ways that are easier to show than to claim.
There is nobody to hand it over to
On a typical project, a team builds something and hands it over. Whatever was hard to maintain becomes someone else’s problem, usually without anyone intending it to.
When the product is yours, the handover never comes. The shortcut taken in week two is the bug you fix in month four. The vague name is the one you misread late at night. The feature added for a demo is the one you keep testing forever. Maintainability stops being a principle and becomes a cost you feel every day.
It also changes what “finished” means. A feature is finished when the next person can change it safely: when its tests say what it must do, its names say what it is, and its odd corners carry a note explaining why they are odd. Without those, a feature is only finished until somebody touches it.
That is the habit we bring to client work: building as if we will be the ones living with it, because on our own product we are.
Scope is a decision you keep making
Every product has more good ideas than time. On ours, the list of things the first release would not do was written down as carefully as the list of things it would, and the order of work was fixed early: the web portal and the public passport page first, the mobile app second.
Writing it down once turned out not to be enough. Scope is not settled at the start. It is decided again every week, each time a new idea arrives looking urgent. What keeps a release on course is making each new idea replace something rather than join the list.
On a client project, that becomes a practical service. We keep the “not now” list, and we make the trade visible whenever something new comes in. “Yes, and here is what moves” is more useful than a yes to everything and a missed date.
There is a second effect. When our own time and money pay for every feature, the question “is this worth building?” gets a much sharper answer. We bring that sharpness to client work too, because a client’s budget deserves the same scrutiny as ours.
The costs you only see after launch
Launch day is a milestone for a project and a starting line for a product. Running one ourselves means we meet everything that comes after it: the backups, the monitoring, the updates and the bills.
Our product’s database is backed up by a script of our own, and that backup has been restored in a drill, because a backup nobody has restored is only a hope. The live service can be asked whether it is healthy, and it is checked from outside, so we hear about a problem before a user has to report it. Dependencies are scanned for known vulnerabilities before anything ships. Hosting runs under a spending limit, so a mistake cannot quietly turn into a large invoice.
None of this is visible in a demo, and all of it is part of the cost of owning software. When we estimate a project, we include it, and we make sure the client knows what it will take to keep the product healthy once we are no longer changing it every day.
Write down why, not just what
A codebase records what was built. It rarely records why. Six months later nobody remembers whether an odd constraint was a mistake or a hard-won lesson, so it is either kept forever or removed at exactly the wrong moment.
Our product keeps a decision log next to its plan, and where a decision changes the plan, the log wins. Each operational document also carries the date it was last checked against the live system. That detail came from experience: a line that was true when it was written can be made false the next day by a change somewhere else. The date tells a reader how far to trust it.
For a client, the same habit means that when a project ends you are left with more than code: the reasons behind the decisions, written where the next person will look.
Turn repeated mistakes into checks
Some mistakes happen once. Others come back in a new form every few weeks. For those, a reminder does not work. A check does.
Our product runs a set of automated checks before any change is accepted, and each exists because one particular kind of defect got through once. One fails the build if an internal specification reference slips into text that people read. Another catches a code pattern that makes a value arrive empty without any error. None of them is clever. Each one closes a door that someone would otherwise have to remember to keep shut.
When the same problem appears twice, the fix is not more care. It is a check that makes the third time impossible. A check also outlives the people who remember why it was needed, which a reminder never does.
Rules that matter belong in the system
Some rules are too important to live only in application code. In the battery passport, a published passport is never edited in place: a change creates a new version. Lifecycle events are only ever added, never rewritten. A missing value is shown as unavailable, never stored as zero. The database itself enforces those rules, and tests cover them, so no screen, script or future feature can quietly break them.
Not every product needs that much rigour. But every product has a few rules that must never be broken, and it is worth knowing which ones they are and where they are enforced before the first line of code is written.
“Done” means working where it matters
Merged is not done. Deployed is not done either, if nobody has looked. On our own product, nothing reaches production until someone promotes it, and only after every check has passed on that exact commit; the question afterwards is not whether the code went out but whether it works for the people it is for. For a mobile app that includes a pass on a real phone, because no automated test sees the camera, the permission prompts or how a screen sits on an actual display.
What this means for a client project
None of this is a methodology we sell. It is what running a product of our own has taught us to do by default. On a project for someone else it shows up as:
- A clear question for the first release, and a written list of what it will leave out.
- Decisions recorded with their reasons, dated, where the next developer will find them.
- Checks for the mistakes that repeat, so quality does not depend on memory.
- The critical rules enforced by the system, not by good intentions.
- Testing where people use it: on real devices, in real conditions, with realistic data.
- Thinking about year two, because that is where most of the cost of software lives.
The part of a project a client lives with longest is everything after launch. Running our own product keeps that part in view from the first day.
We did not set out to learn any of this. It arrived one inconvenience at a time, the way lessons do when there is nobody else to absorb them. That is exactly why they stay learned.
