<story><title>Ask HN: What&apos;s a build vs. buy decision that you got wrong?</title><text>What are services&amp;#x2F;products that you built and wished you had bought?&lt;p&gt;Have you bought something that you had to scrap and build yourself anyways?</text></story><parent_chain><item><author>mjr00</author><text>&amp;quot;Workflow engines&amp;quot; and their close cousins &amp;quot;DSLs&amp;quot; are the ultimate newbie trap. In theory, it&amp;#x27;s awesome for everyone: programmers get to work on interesting, abstract problems like distributed systems, syntax parsing, event-based architectures, and &amp;quot;business users&amp;quot; get to make changes to &amp;quot;business rules&amp;quot; without bothering developers or impacting feature roadmaps. Win-win, right?&lt;p&gt;In reality you just end up making a shitty, nerfed version of a programming language, that business users can&amp;#x27;t understand, because you still have to understand conditional logic to model workflows, oh and your documentation is terrible because devs don&amp;#x27;t bother with the boring stuff. Most of the time the devs end up implementing the workflows anyway because they don&amp;#x27;t actually work properly.&lt;p&gt;If you really need a workflow engine definitely use something off-the-shelf, but I would go so far as to say that in the 95% case, you don&amp;#x27;t even need a workflow engine: you need a developer who is capable of writing some python scripts. Even if you pay a developer a full salary to do nothing but sit around and make changes to Python scripts on-demand, that&amp;#x27;s still going to be &lt;i&gt;way&lt;/i&gt; cheaper than the complicated workflow engine solution, which will probably require a team (or multiple teams) to maintain.</text></item><item><author>ctvo</author><text>Workflow engines. Every company develops one base off of queues or some form of async messaging. Works great when prototyping and your initial customer base. Works less great as you grow, add more complicated features, and realize you didn&amp;#x27;t have the distributed systems expertise to write this thing to begin with. It doesn&amp;#x27;t handle any of the common edge cases, and is increasingly painful to operate, needing constant babysitting.&lt;p&gt;Use Temporal, StepFunctions, &lt;i&gt;something&lt;/i&gt; and try to avoid this urge.</text></item></parent_chain><comment><author>rwmj</author><text>This reminded me of the time I wrote a mini-language for querying web server log files and generating reports (this was early 2000s) so you could answer questions like &lt;i&gt;&amp;quot;how many users searched for &amp;#x27;cyprus flight&amp;#x27; per day and went on to purchase a holiday?&amp;quot;&lt;/i&gt;.  With a nice web-based interface etc.&lt;p&gt;It was a disaster of course.  The business people weren&amp;#x27;t programmers, had no understanding of programming, didn&amp;#x27;t want to learn programming even greatly simplified with docs and examples, and I ended up translating their queries into code anyway.  So essentially I had written a DSL for myself.</text></comment>
<story><title>Ask HN: What&apos;s a build vs. buy decision that you got wrong?</title><text>What are services&amp;#x2F;products that you built and wished you had bought?&lt;p&gt;Have you bought something that you had to scrap and build yourself anyways?</text></story><parent_chain><item><author>mjr00</author><text>&amp;quot;Workflow engines&amp;quot; and their close cousins &amp;quot;DSLs&amp;quot; are the ultimate newbie trap. In theory, it&amp;#x27;s awesome for everyone: programmers get to work on interesting, abstract problems like distributed systems, syntax parsing, event-based architectures, and &amp;quot;business users&amp;quot; get to make changes to &amp;quot;business rules&amp;quot; without bothering developers or impacting feature roadmaps. Win-win, right?&lt;p&gt;In reality you just end up making a shitty, nerfed version of a programming language, that business users can&amp;#x27;t understand, because you still have to understand conditional logic to model workflows, oh and your documentation is terrible because devs don&amp;#x27;t bother with the boring stuff. Most of the time the devs end up implementing the workflows anyway because they don&amp;#x27;t actually work properly.&lt;p&gt;If you really need a workflow engine definitely use something off-the-shelf, but I would go so far as to say that in the 95% case, you don&amp;#x27;t even need a workflow engine: you need a developer who is capable of writing some python scripts. Even if you pay a developer a full salary to do nothing but sit around and make changes to Python scripts on-demand, that&amp;#x27;s still going to be &lt;i&gt;way&lt;/i&gt; cheaper than the complicated workflow engine solution, which will probably require a team (or multiple teams) to maintain.</text></item><item><author>ctvo</author><text>Workflow engines. Every company develops one base off of queues or some form of async messaging. Works great when prototyping and your initial customer base. Works less great as you grow, add more complicated features, and realize you didn&amp;#x27;t have the distributed systems expertise to write this thing to begin with. It doesn&amp;#x27;t handle any of the common edge cases, and is increasingly painful to operate, needing constant babysitting.&lt;p&gt;Use Temporal, StepFunctions, &lt;i&gt;something&lt;/i&gt; and try to avoid this urge.</text></item></parent_chain><comment><author>__MatrixMan__</author><text>&amp;gt; the complicated workflow engine solution ... will probably require a team (or multiple teams) to maintain&lt;p&gt;You can get these &amp;quot;as a service&amp;quot; which might scratch the itch for some.&lt;p&gt;(Disclaimer: I work for a company that sells Airflow-as-a-service and adjacent consulting)</text></comment>