An honest obituary

Today, a tech company dies. As will many others, but this one hurts a little more. It’s my own company.

In late 2025, I started my first tech venture, ETLR. It was built to help manage glue code between web applications, such as web hooks and cron jobs – something I’d rebuilt many times over the years.

Workflow automation wasn’t a new concept. Competitors like n8n had been long established in the market. That said, I believed there was a need for a more serious tool following good engineering principles.

Whilst I was at AMPLYFI, a small team of engineers managed 250+ complex web services for years, with all of the glue code to go with it. How did we manage that? Good CI/CD practices. The only way we could operate at that scale was to implement good observability and follow infrastructure as code, where—surprise—you declare all of your infrastructure as code. It avoids the whole spaghetti drag and drop nonsense, forgotten and incorrect configurations where no one remembers how something was initially setup. Extremely useful when someone accidentally deletes production and you need to spin it back up.

That’s what I would bring to workflow automation at ETLR. A few lines of YAML, automatically deployed from a git repo and you’ve got yourself a repeatable, reliable and auditable workflow without any of the headaches.

It's been 7 months now and there’s still some part of me that believes that there is a market for ETLR, but unfortunately it never took off in the way I had intended.

When I sent an email announcement to our users a few weeks ago stating that we’d be closing up shop, I didn’t get a single response asking me to stop what I was doing. One asked if we could discuss how it works, but no one actually cared that it was being turned off.

If you take anything from this story, it should be:

If you tell your users that you’re taking a feature, capability or product away from them and nobody complains, you don't have product market fit.

Whilst we’re here, let’s take a look at what else might have gone wrong.

Lesson one – don’t ignore the feedback from early validation

I’m a massive proponent of carrying out validation before building anything. I spoke to lots of target users to discover whether this was a real problem, and whether the solution was a good fit. Initial feedback was mixed. Some valued it, some didn’t. Many were already happy with the alternatives that were well supported. I felt that there were enough positive signals to proceed, but in hindsight, this probably wasn’t a burning problem for anyone – which leads us on to lesson two.

Lesson two – build a product worth paying for

200 users signed up to the platform, but no one ever upgraded to the paid plan. Was it my fault for not advertising the upsell well enough within the product? Was I too generous with the free tier? Or perhaps more worryingly, it wasn’t a valuable enough problem worth paying for. n8n was successful because it was mostly targeting non-developers with simple drag and drop. It made automation accessible. DevOps and Software Engineers could already code and they weren’t looking for another paid tool.

Lesson three – don't ignore your target users

One of the strongest repeating signals I got from our DevOps segment was that they wanted an open source solution. They didn’t want to be locked into a new proprietary format with a new vendor. This customer segment is highly skeptical, cost focused and wants to de-risk new technology as much as possible. After all, they’re responsible for the reliability of the tech stack. We often discussed whether we should open source connectors, the runner and even the entire control plane itself. In hindsight, a successful product in this category often open sources some aspect of the platform, and then offers a cloud service as a value add on top. Proceed with caution!

Lesson four – technology moves quickly

Agents and agentic coding have come on leaps and bounds in the past 6 months. When we first created ETLR, agent harnesses like Claude Code and GitHub Copilot were in their infancy. They couldn’t be trusted to create reliable code. The idea of a deterministic workflow defined short hand in YAML felt more valuable back then. But honestly, it’s no longer an issue. Now you can trust the output of agents and they are massively flexible. Way easier than declaring a YAML file. Writing glue code is not the same painful issue anymore.

Lesson five – stay focused

I've spoken about this a lot recently, but I’ve been involved in a lot of different projects over the last year. I wanted to believe that AI advancements made it possible to work on lots of products at the same time. It’s true that you can now experiment with more, but the reality is that to create a new product and make it successful, it’s a real grind and requires your full attention.

All of this is to say, whether the failure of ETLR was due to external factors, or myself making bad decisions about the product and category, the signals are clear. There is no need for ETLR, and today it must die.

Where will my focus now go? If you’re interested in continuing to follow my journey, check out my latest product, Pendra – Private AI infrastructure for open models. It’s now getting the full focus that it deserves.