TopicsStartup FundamentalsFundraisingThe Nordic Edge

Lessons from Building Developer Tools: What I Learned at Realm

last year · 853 words · 5 min read

developer-experienceproduct-managementstartupsdatabases

Lessons from Building Developer Tools: What I Learned at Realm

When we started Realm, we set out to replace SQLite as the default database for mobile apps. It was an audacious goal—SQLite had been the standard for over a decade. But we believed we could build something better by focusing relentlessly on developer experience.

Here's what we learned along the way.

Developers Are Different Users

Building for developers requires a different mindset than building for typical business users.

They read your code. Developers will look at your source code, your stack traces, and your dependencies. They'll form opinions based on what they find.

They value their time intensely. A developer evaluating your tool will give you about 15 minutes. If they can't get a basic example working in that time, they're gone.

They talk to each other. Developer communities are tight-knit. One influential developer's opinion can make or break adoption.

The 5-Minute Rule

We obsessed over time-to-first-value. Our goal was simple: a developer should be able to go from npm install realm to working code in under 5 minutes.

This meant:

// This had to just work, immediately
import Realm from 'realm';

const TaskSchema = {
  name: 'Task',
  properties: {
    name: 'string',
    done: 'bool',
  },
};

const realm = new Realm({ schema: [TaskSchema] });

realm.write(() => {
  realm.create('Task', { name: 'Learn Realm', done: false });
});

const tasks = realm.objects('Task');
console.log(tasks.length); // 1

Every friction point we removed increased conversion. We measured:

  • Time to install
  • Time to first query
  • Time to first sync (for Realm Sync)

Documentation Is Product

We invested heavily in documentation—not as an afterthought, but as a core product feature.

Structure matters. We organized docs around use cases, not features:

  • "Getting Started" (the first 5 minutes)
  • "Working with Data" (common patterns)
  • "Syncing Data" (advanced features)
  • "Migration Guide" (for existing users)

Examples must work. Every code example in our docs was tested in CI. Broken examples destroy trust.

Error messages are documentation. When something goes wrong, the error message is often the first "documentation" a developer reads:

// Bad
Error: Invalid schema

// Good
Error: Invalid schema for 'Task' model.
Property 'dueDate' has type 'Date' but received 'string'.
Did you mean to use: new Date('2024-01-15')?

The Power of Defaults

Smart defaults dramatically improve developer experience. We learned to optimize for the common case while allowing customization for edge cases.

Example: Query syntax

// Simple case: just works
const doneTasks = realm.objects('Task').filtered('done == true');

// Advanced case: still possible
const complexQuery = realm
  .objects('Task')
  .filtered('done == $0 AND priority > $1', true, 5)
  .sorted('dueDate', true);

Community Building

Developer tools live or die by their community. We invested in:

Open source. We open-sourced the core database engine. This built trust and enabled contributions.

Stack Overflow presence. We monitored and answered questions daily. Response time mattered—developers move fast.

Sample apps. We built and maintained sample applications showing real-world usage patterns.

Meetups and conferences. Face-to-face interaction with developers was invaluable for understanding pain points.

Metrics That Matter

For developer tools, traditional SaaS metrics don't tell the whole story. We tracked:

  • Time to first value: How long until a developer's first successful query?
  • Documentation bounce rate: Are developers finding what they need?
  • Stack Overflow sentiment: What's the tone of questions and answers?
  • GitHub stars and forks: Vanity metric, but indicative of interest
  • Production usage: How many apps actually ship with our tool?

What We Got Wrong

Not everything worked. Some lessons came from failures:

Over-engineering the API. Early versions had too many options. Simplicity wins.

Ignoring migration pain. Upgrading between versions was initially too hard. We lost users to the friction.

Slow response to issues. Early on, we didn't prioritize bug reports enough. Developers remember when you leave them stuck.

The Compounding Effect

Good developer experience compounds. When developers have a great experience:

  1. They tell other developers
  2. They write blog posts and tutorials
  3. They answer questions on Stack Overflow
  4. They contribute to your docs and code
  5. They become advocates within their companies

This creates a flywheel that's hard for competitors to replicate.

Advice for Developer Tool Builders

If you're building tools for developers:

  1. Use your own product obsessively. Dogfooding reveals issues docs can't.

  2. Invest in error messages. They're read more than your docs.

  3. Make the simple things simple. Complexity should be opt-in.

  4. Respond quickly to issues. A fast response, even if you can't fix it immediately, builds goodwill.

  5. Build in public. Share your roadmap, discuss tradeoffs, admit mistakes.

The Outcome

Realm grew to power applications with hundreds of millions of users. The company was acquired by MongoDB in 2019. Looking back, our focus on developer experience was the key differentiator.

The database market is crowded. Performance and features matter, but they're table stakes. What separated us was the feeling developers had when using our tool: that we understood their problems and respected their time.

That's the lesson I carry into every product I work on now.

If you want to go deeper on the Realm technical architecture — MVCC, zero-copy reads, the sync engine, and what I'd do differently — I wrote a separate technical deep-dive: How Realm Works: The Database Architecture Behind 2 Billion Installs.

Related Posts