How we built our workflow engine
In this technical retrospective (2022), @lawrjone shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE 4 points
TOTAL DISCUSSIONS 1 comments
Author here!
This is a write-up about how we built a core part of our product, which is the workflow engine.
Workflows are more complex than most of our features, powered by something akin to a small programming language designed to help model things like users, teams, PagerDuty services, etc. on behalf of our customers.
The post is a behind-the-scenes view of both how the feature works and insight into our goals and methodology as a team, including an evaluation of whether the up-front investment was worthwhile.
I think it's rare that people go into both the technical and human side of building a feature, and hope this can be a case study of how engineering projects get done at a start-up like ours!