I've been thinking about starting a new project using my go-to tech: Clojure. For me, it's the best tool around, and I’m always surprised that more people don’t see its potential. It’s a fantastic multi-purpose language design to build solid software, so I asked myself: What’s a good fit for it where I feel confident building something meaningful in my spare time? After some tinkering, I come up with this idea: A workflow automation tool. Think Zapier, but designed specifically for small and medium-sized businesses that need reliable and observable workflows. I believe Clojure’s strengths—its "everything is a map" data model and its powerful concurrency support—make it the perfect language for building robust API integrations. Why Build Another Workflow Tool? There are plenty of workflow automation tools like Zapier that offer a huge range of integrations. I can't challenge these platforms by being cheaper or offering more integrations. So, I started thinking: Why don’t I use these tools more often in my day-to-day work? I think it’s because of reliability, observability, and missing collaboration features. These platforms often feel like black boxes—when something goes wrong, it's hard to know why. Collaboration is often an afterthought: you need the business++ plan and the UX for it has been shoved into the product — hard to use something like that if you're in an organization larger than a startup. Worse for me, workflows are not easily observable: you're left hoping everything works as expected. In today’s world, there is no reason to guess whether your software is functioning. With the right tech, you can observe and ensure that everything works as expected. Building Software That “Just Works” I’m a big believer in building software that delivers value from day one. No overselling. No bugs lurking beneath the surface. Too many SaaS promise a lot but deliver a half-baked experience — as soon as you get out of the main use case of the tool, you have to contact the support to figure out what is going on. Nobody wants to spend time on a half-bake tool selling you promises. Users want value now, not after your next fundraising. My Initial Target I’m focusing on the basics: Create and edit workflows: The UX to configure the tool. View workflow execution: View what works and what does not Webhook integration: The basic block to build on top off User roles and permissions: Enable teams to work together seamlessly Export and edit workflows programmatically: Building block that allows integration to developer tools Workflow status via API: Clear visibility into the state of every workflow. On-demand pricing: Pay for what you use, when you use it. Once these core functionalities are in place, I’ll start adding more integrations—things like email, AWS APIs, tools for deployment, Notion (I use it a lot), Slack, human interaction workflows, and Google Workspace. Over time, I’ll figure out what other integrations make sense for users who share my vision of a workflow platform. Adding LLM support seems obvious in today’s market. Every company now needs to integrate with LLMs, managing things like throttling, token usage, and cost monitoring. I see real value in handling that complexity for users. Of course, I could be wrong—maybe companies will prefer to build their own LLM integrations. That reminds me of the beginning of the mobile apps business, I thought building mobile apps would be a flop because companies would have to maintain applications for search platforms and still do a responsive website to convince users to install their application. I was dead wrong, and now most companies maintain two mobile applications and at least one website, and eventually two when they have a website for mobile. The Challenge of Selling How will I market this project? Honestly, I’m not sure yet. My initial plan is to create something useful for myself that’s solid enough for others to use. Whether I manage to find users is still a big question mark, but I know I need to figure it out and articulate my value proposition clearly. Why I Will Succeed I’m confident in my ability to build this. I know how to leverage infrastructure to create something that’s both solid and scalable. With Clojure’s strengths and my experience, I believe I can deliver something valuable. Why I Could Fail Marketing and sales: This is my weakest area. I have limited experience, and finding the first users will be tricky. I also don’t enjoy platforms like Twitter, and this kind of social website with a tidbit of knowledge and a lot of noise. I prefer long-form content, but it’s harder to reach people that way and build an audience. I need to not underestimate the issue. Market misjudgment: It’s possible that the workflow automation market won’t take off the way I expect. Companies will keep building integration after integration and discover over time that it is a costly handover to build and *maintain (*emphasis on maintaining as software estimation only accounts for the cost of building things and not on the cost of observing, debugging, upgrading, interconnecting, …) Time constraints: Balancing family, a day job and other interests means I might not be able to dedicate as much time to this project as I’d like. Why This Will Make Me Happy Ultimately, it’s about the journey. This project will push me out of my comfort zone and challenge me to learn new things, not just in my area of expertise, but across the full software lifecycle. I’m excited to tackle the problems I’m less familiar with and grow from these experiences, regardless of the final outcome. I've been thinking about starting a new project using my go-to tech: Clojure. For me, it's the best tool around, and I’m always surprised that more people don’t see its potential. It’s a fantastic multi-purpose language design to build solid software, so I asked myself: What’s a good fit for it where I feel confident building something meaningful in my spare time? What’s a good fit for it where I feel confident building something meaningful in my spare time? After some tinkering, I come up with this idea: A workflow automation tool. Think Zapier, but designed specifically for small and medium-sized businesses that need reliable and observable workflows. I believe Clojure’s strengths—its "everything is a map" data model and its powerful concurrency support—make it the perfect language for building robust API integrations. Why Build Another Workflow Tool? There are plenty of workflow automation tools like Zapier that offer a huge range of integrations. I can't challenge these platforms by being cheaper or offering more integrations. So, I started thinking: Why don’t I use these tools more often in my day-to-day work? Why don’t I use these tools more often in my day-to-day work? I think it’s because of reliability, observability, and missing collaboration features. These platforms often feel like black boxes—when something goes wrong, it's hard to know why. Collaboration is often an afterthought: you need the business++ plan and the UX for it has been shoved into the product — hard to use something like that if you're in an organization larger than a startup. Worse for me, workflows are not easily observable: you're left hoping everything works as expected. In today’s world, there is no reason to guess whether your software is functioning. With the right tech, you can observe and ensure that everything works as expected. Building Software That “Just Works” I’m a big believer in building software that delivers value from day one. No overselling. No bugs lurking beneath the surface. Too many SaaS promise a lot but deliver a half-baked experience — as soon as you get out of the main use case of the tool, you have to contact the support to figure out what is going on. Nobody wants to spend time on a half-bake tool selling you promises. Users want value now, not after your next fundraising. My Initial Target I’m focusing on the basics: Create and edit workflows: The UX to configure the tool. View workflow execution: View what works and what does not Webhook integration: The basic block to build on top off User roles and permissions: Enable teams to work together seamlessly Export and edit workflows programmatically: Building block that allows integration to developer tools Workflow status via API: Clear visibility into the state of every workflow. On-demand pricing: Pay for what you use, when you use it. Create and edit workflows : The UX to configure the tool. Create and edit workflows View workflow execution: View what works and what does not View workflow execution: Webhook integration : The basic block to build on top off Webhook integration User roles and permissions : Enable teams to work together seamlessly User roles and permissions Export and edit workflows programmatically : Building block that allows integration to developer tools Export and edit workflows programmatically Workflow status via API : Clear visibility into the state of every workflow. Workflow status via API On-demand pricing : Pay for what you use, when you use it. On-demand pricing Once these core functionalities are in place, I’ll start adding more integrations—things like email, AWS APIs, tools for deployment, Notion (I use it a lot), Slack, human interaction workflows, and Google Workspace. Over time, I’ll figure out what other integrations make sense for users who share my vision of a workflow platform. Adding LLM support seems obvious in today’s market. Every company now needs to integrate with LLMs, managing things like throttling, token usage, and cost monitoring. I see real value in handling that complexity for users. Of course, I could be wrong—maybe companies will prefer to build their own LLM integrations. That reminds me of the beginning of the mobile apps business, I thought building mobile apps would be a flop because companies would have to maintain applications for search platforms and still do a responsive website to convince users to install their application. I was dead wrong, and now most companies maintain two mobile applications and at least one website, and eventually two when they have a website for mobile. The Challenge of Selling How will I market this project? Honestly, I’m not sure yet. My initial plan is to create something useful for myself that’s solid enough for others to use. Whether I manage to find users is still a big question mark, but I know I need to figure it out and articulate my value proposition clearly. Why I Will Succeed I’m confident in my ability to build this. I know how to leverage infrastructure to create something that’s both solid and scalable. With Clojure’s strengths and my experience, I believe I can deliver something valuable. Why I Could Fail Marketing and sales: This is my weakest area. I have limited experience, and finding the first users will be tricky. I also don’t enjoy platforms like Twitter, and this kind of social website with a tidbit of knowledge and a lot of noise. I prefer long-form content, but it’s harder to reach people that way and build an audience. I need to not underestimate the issue. Market misjudgment: It’s possible that the workflow automation market won’t take off the way I expect. Companies will keep building integration after integration and discover over time that it is a costly handover to build and *maintain (*emphasis on maintaining as software estimation only accounts for the cost of building things and not on the cost of observing, debugging, upgrading, interconnecting, …) Time constraints: Balancing family, a day job and other interests means I might not be able to dedicate as much time to this project as I’d like. Marketing and sales : This is my weakest area. I have limited experience, and finding the first users will be tricky. I also don’t enjoy platforms like Twitter, and this kind of social website with a tidbit of knowledge and a lot of noise. I prefer long-form content, but it’s harder to reach people that way and build an audience. I need to not underestimate the issue. Marketing and sales Market misjudgment : It’s possible that the workflow automation market won’t take off the way I expect. Companies will keep building integration after integration and discover over time that it is a costly handover to build and *maintain (*emphasis on maintaining as software estimation only accounts for the cost of building things and not on the cost of observing, debugging, upgrading, interconnecting, …) Market misjudgment Time constraints : Balancing family, a day job and other interests means I might not be able to dedicate as much time to this project as I’d like. Time constraints Why This Will Make Me Happy Ultimately, it’s about the journey. This project will push me out of my comfort zone and challenge me to learn new things, not just in my area of expertise, but across the full software lifecycle. I’m excited to tackle the problems I’m less familiar with and grow from these experiences, regardless of the final outcome.
