trolls.dev has one rule that shapes everything else: we only build products we run ourselves. We don’t take client or agency projects. If it has our name on it, we’re the ones responsible when it breaks.
That responsibility changes what we build and how carefully we scope it.
What gets lost at handoff
When a project’s finish line is the handoff, delivery can take priority over maintenance. It’s tempting to polish the demo while leaving edge cases as “known issues” for the next team to handle.
Even a careful handoff can separate the builders from what happens next. The people who made the design decisions may never hear where real users get stuck.
Operating is where the learning is
Running a product shows you which features people use and where a supposedly quick flow slows them down. It also exposes failures you didn’t anticipate, such as what breaks when a link gets shared somewhere unexpected. We read every email from users, and those reports help us decide what to fix next.
After launch, we get to see which of our assumptions survived actual use.
Maintenance limits the scope
Knowing we’ll operate whatever we ship is the best scope-control mechanism we’ve found. Every feature needs maintenance and support for as long as the product lives. We have to account for that work before adding it. It’s a big part of why our products stay small on purpose.
Long-haul software
It’s frustrating to depend on a tool that later fills with ads or gets abandoned. We have a personal reason to keep ours useful: they’re products we wanted for ourselves, and we’re not building them for a quick sale. DReader stays ad-free because we’re its heaviest users. ganttchart.ai stays fast and simple because we make our own timelines with it.
Using and operating the software keeps its problems in front of us. When something is slow or confusing, we have to deal with it too.