We believe the tools are the problem, not the people.

We built jotsum for ourselves first. Neither of us is formally diagnosed — like a lot of adults, we spent childhood and then two decades of working life not understanding why things that seemed easy for most people were so hard for us. It's only as the conversation around ADHD has opened up that we've come to recognise ourselves in it. What we can say for certain is this: the way our minds work — working memory that drops things, focus that won't be scheduled, folders that swallow whatever goes into them — is why every productivity tool we ever tried eventually failed us.

The breaking point came during a co-living residency. A community we were part of struggled to coordinate. Important decisions got lost in chat scrollback. Meeting notes scattered across Google Docs became "unwieldy and difficult to navigate." Quieter voices got drowned out by louder ones in group chats. Small coordination tasks triggered push notifications that raised everyone's stress levels.

We realised: the problem isn't that people are disorganised — it's that most tools expect you to organise while capturing. But not all minds work that way. Ideas come in bursts. Organisation comes later — if you even remember the idea existed.

So we built something for ourselves. No branding, no marketing, no pitch decks. A tool we'd actually use. We put an early, buggy version into the hands of friends and family with genuine needs. Then Pluk Farm CSA tried it — they'd been searching for coordination tools for over a year. They switched their entire system within 24 hours. All 8 members were using it daily within 2 weeks.

We're not building tools for how we think people should work. We're building tools for how humans actually work.

We rejected a lot of standard startup practices. Instead of building a minimal set of features, we built a full suite to minimally viable states. Instead of prototyping and testing, we prioritised development and put early, buggy versions into real use. Instead of branding and marketing first, we delayed everything until we understood what people actually used it for.

This approach — building for ourselves and friends first — meant we saved time on design cycles and spent it on features. It meant early testers weren't test subjects but partners. It meant the tool could become what it needed to be, not what we'd already branded it as.

Designing tools for collectives is an exercise in designing for the pluriverse. We're building flexible infrastructure communities can adapt, not standardised workflows they must adopt.