Community Driven Development

i want to share a few thoughts on product iteration at TRMNL and "community driven development" seems like a good encapsulation. apparently this term is taken by folks in the city planning space, but today we'll share it.

when tech founders (aka product managers) ponder what their platform should do and who it should serve, the starting point is usually a figment of their imagination.

in November 2023 i jumped out of the shower and shouted at my unsuspecting wife -- "i have a new idea... Bloomberg Terminal for everything!" a few days later TRMNL was born.

over time that idea kernel becomes a vision, which grows in step with the momentum of feedback loops. on Black Friday i bought a Raspberry Pi and downloaded the Waveshare e-paper driver, leading to hours of confusion about how graphics are generated on a device. my lack of deeper technical knowledge led to "server generates image, device just displays it" logic, now dubbed as our pull architecture.

eventually this founder has a working product that does pretty much whatever they imagined. it's a great feeling that most people reading this post have probably felt, given TRMNL is a community of builders.

but now what? as you hire people and set goals, where do the macro (+ micro) ideas come from? how do you prioritize what to focus on next?

community driven development

at first glance this term may sound like the following:

1. ask customers what they want
2. build it

but in our experience this isn't really true. we've rejected many, many feature requests, including the most popular (repeated) ones. for example:

• clock with < 1 minute refresh
• touch screen
• more buttons
• color e-ink panels (whoops, stay tuned)
• multiple sleep schedules

so no, community development is not a strategy to defer dreaming and get complacent. it is providing tools for the community to help themselves.

at TRMNL we found this groove in DX (developer experience). TRMNL team members make plugins, community hackers make plugins. we design layouts, the community designs layouts. we use dozens of API endpoints, the (BYOS) community needs dozens of endpoints.

thus developer happiness == customer happiness, so long as our customers are tech savvy.

expanding our audience

although we don't have any venture capitalists, there's always pressure to grow market share by appealing to other types of users. and indeed this has happened at TRMNL, just accidentally.

a typical customer relationship:

1. hears about TRMNL on a tech review / reddit post
2. gets a device
3. spouse sees it
4. device moves to common area of the home
5. plugin requirements change from Hacker News to family calendar
6. gets another device

we didn't aim to achieve this flywheel, but we have made calendars and weather and other family-oriented plugins a lot better as a natural progression.

so when 2025 was in its final stages, a few weeks ago we had an internal chat: should TRMNL explore retail? should we be on the shelves at Costco, or fulfilled by Amazon?

in small batch experiments with 3rd parties reselling TRMNL, customer support ticket volume and return requests are higher. this hurts team morale and makes me think we're getting greedy.

so yeah, audience expansion "works." we're just not interested.

speed == quality

in my 20s i was a full-time marketer and read 100s of books on consumer psychology, sales, persuasion and so on. from one of those books i recall a scientific study about 2 groups of people.

each group was asked to make a contraption, let's say a box. but the first group had to make 100 within a few hours. the second group was allowed to spend the entire time making 1, as high quality as possible.

at the end, the former group's 100th box was better than the latter group's 1st (last) box. this lesson has stuck with me in all my projects and is why at TRMNL we:

• push directly to master (sometimes)
• seldom require code reviews
• don't have protected branches
• empower everyone to get involved in product, even if not their job title

if we made things for a mission-critical industry, say Aerospace, this would get us in a lot of trouble. but because we know our audience (hackers), it's fine. not that i want bugs in prod, but because our community will help identify and fix them. ergo: community driven development.

thoughts on 2026

i put a few teasers in 2025 in review, but here are some other things i look forward to:

• thousands of published plugins
• at least 2x new products
• enterprise collaborations (including on-prem hosting support)
• IRL events at our Berlin warehouse
• open sourcing more of our secret sauce
• reducing prices (again)
• behind the scenes video content
• a 3rd warehouse where we make enclosures by-hand in the USA
• team retreat and live Town Hall (coming this March)

to the community reading this, keep your ideas and PRs coming. we're on the same team.