Why we built our own tools instead of using what's out there

We give clients advice about when to build custom software and when to use existing tools. It would be inconsistent not to apply that same thinking to ourselves.

So when we decided to build k-notes, k-tasks, and k-cv, people reasonably asked: why? Notion exists. Trello exists. There are dozens of CV builders. What made you think you needed to build your own?

Here's the honest answer.

We wanted tools that behaved the way we think

Most productivity software is designed for the average user across all possible use cases. That's a reasonable product strategy. It also means a lot of complexity that most people never use.

We take notes constantly — during calls, while reading, when an idea surfaces at 11pm. We wanted an editor that opened instantly, saved automatically, and got out of the way. Notion is excellent software, but it's not that. Every document lives inside a workspace system that takes a moment to navigate. We kept reaching for a notes app that opened like a blank page.

So we built one.

The same thing happened with tasks. We used Trello for years. Then Asana. Then Linear. Each solved some problems and introduced others. We wanted a kanban tool where creating a task took one click, where the interface didn't require training to understand, and where the free tier didn't feel like a demo. We built that instead.

We care about data ownership

We're a European company, and data practices that are normal in Silicon Valley aren't always acceptable here — legally or ethically. When you use a free American SaaS tool, the business model is usually advertising or data licensing. Your notes, your tasks, your career documents: they're the product.

Our products run on European infrastructure (Neon Postgres with EU data residency) and we have a simple relationship with users: you pay a small fee, we store your data, we don't sell it or mine it. GDPR compliance isn't a legal checkbox for us — it's the design requirement.

Building software makes you a better development partner

Every time we've shipped a product feature, we've encountered the same problems our clients face: unclear requirements, scope creep, the tension between speed and quality, decisions that seemed small and turned out to be foundational.

Running our own products has made us better advisors. When a client says "we just want to add one more thing," we understand exactly what that usually means for a timeline. When someone asks about database schema choices, we've been in those conversations at 2am trying to fix a production problem.

Skin in the game changes how you think about software.

What we learned (and what surprised us)

The hardest part wasn't the engineering. It was deciding what not to build.

Every product we ship has a list of features we deliberately left out. k-notes doesn't have a wiki mode. k-tasks doesn't have a Gantt chart. k-cv doesn't have AI that writes your experience section for you. Users ask for these things. We say no.

This is harder than it sounds. The instinct when someone asks for a feature is to say yes. Saying no requires a clear sense of what the product is for — and a willingness to disappoint some potential users to serve the core ones better.

The apps work because of what we removed, not what we added.

Why we're telling you this

We're not telling this story to suggest that building custom tools is always the right move. It isn't. There are excellent existing products for most common needs, and using them is usually the sensible choice.

But for us, building our own tools wasn't vanity. It was the only way to have exactly what we needed, aligned with our values, that we could maintain and improve ourselves. The products exist because we use them, not as a portfolio exercise.

If you're building something and want to talk through whether to build or buy, we have a strong opinion and won't just tell you what you want to hear.