Articles

Making Authentication Simpler in MCP

If you’re working with AI tools or data platforms, you might start hearing more about something called MCP – the Model Context Protocol. It’s an open standard developed by Anthropic that aims to standardise how AI models connect with external tools, data sources, and systems. But one topic that’s been tripping people up is authentication—basically, how we make sure only the right people and apps get access. Let’s talk about how to make this simpler, not harder.

How to start and grow a platform product

A platform product/business, also referred to as a ‘plugin’ or ’embedded software,’ is a product that lives inside a larger platform. Slack apps, Shopify apps, Monday apps etc. are all examples of such products. Why build inside another platform? I’ve built two profitable platform products so far (Canopact, Data Importer). I’ve also tried to build stand-alone SaaS products, which were an order of magnitude harder to launch and get off the ground.

How I prioritise feature requests for Data Importer

I get a fair amount of feature requests for Data Importer (currently 10+ per week). Here’s how I go about deciding what to work on and when. After a period of just prioritising based on vibes (which I still do sometimes), I thought it was time to look at some of the popular feature request frameworks out there and see which ones would best align with the product I’m building.

The best way to get early users in a market you have no experience in

Conventional start-up wisdom tells us that the best way to get early traction for your product is to launch into a market/industry you already have an understanding of, a network within, an unfair advantage on etc. This is very good advice. But sometimes (against our better judgement) we don’t want to build a product inside a market we already know well. Maybe you’re excited about a problem in a different market, bored to death of the industry you’ve been working in for 10+ years, or think there’s more growth potential in another area.

How I prioritise feature requests for Data Importer

Planted February 11, 2025

I get a fair amount of feature requests for Data Importer (currently 10+ per week). Here’s how I go about deciding what to work on and when.

After a period of just prioritising based on vibes (which I still do sometimes), I thought it was time to look at some of the popular feature request frameworks out there and see which ones would best align with the product I’m building.

There were a few criteria that I was looking for:

  • Not too overkill: As a part-time solo bootstrapped product, I don’t want to spend more time prioritising the product than actually shipping it.
  • Fast to apply: I need a system where I can quickly run a feature request through some mental checks and have a good sense of priority without needing to write a 10-page strategy document.
  • Flexible to gut feel: I wanted something that supports a structured approach but also allows space for instinct and qualitative judgement.

In the end, I settled on the value vs effort matrix. It aligned well with the above criteria for Data Importer and, honestly, I think most feature prioritisation frameworks are just a variation on this core concept anyway.

Quantifying Effort

Fairly straightforward. Having worked on the product for some time, I have a good sense of estimating development time for a feature. Obviously there will always be a degree of error in this, but in general I find that it converges toward reasonable accuracy (i.e. underestimated features are offset by underestimated features)

Quantifying Value

Definitely not straightforward. Quantifying value is much harder than quantifying effort. Trying to assign a numeric score to value often feels forced — but having some structure helps.

For Data Importer, I usually look at two main lenses:

  • Closeness to revenue: How directly will this feature increase acquisition, conversion, or retention? If a feature can meaningfully reduce churn or close a sale that’s already in the pipeline, it gets a boost in priority.
  • Relevance to the user base: What percentage of my existing (or ideal) customers would benefit from this? Something that helps 80% of users is usually higher priority than something that helps 5%, unless the 5% are a particularly valuable segment.

Of course, there are flaws in this. Some features may have strategic or long-term value that isn’t obvious right now. Plus, technical debt, infrastructure improvements, and product polish don’t always show up clearly in a “value score,” but neglecting them can be fatal over time.

At the end of the day, prioritisation is an imperfect science. The goal isn’t to be correct every time — it’s to be approximately right most of the time.

Prioritise Based on Vibes

I’d love to say I use the above framework every time I plan out what I’m going to work on each month, week, or day. The truth is, I don’t — and often for good reason.

Sometimes, motivation is a finite resource. There are days when the idea of tackling a big, high-effort, high-value feature feels like pulling teeth. On those days, it’s better to knock out a few smaller wins to regain momentum and keep the muscle of shipping alive.

I’d rather ship something small than ship nothing at all. Analysis paralysis is one of the biggest hurdles to overcome as a solo builder.

There’s a reason why product management is often described as both an art and a science.