TheLunarEngine
Discuss a project
Journal

Delivery7 min read

Implement what you have, or set it up from scratch?

The two ways we automate a system: implementing software you already run or have chosen, or a full setup. How we decide, and what each looks like week to week.

  • Node.js
  • Python
  • Jira
  • TypeScript
  • PostgreSQL
  • React Native

We automate systems, and every engagement starts with one question: is there already a system worth keeping? Sometimes the best software is the one your team already knows, wired up properly. Sometimes the work needs its own platform. We do both, on the same foundations.

Two routes: implement an existing system, or full setupStarting from the question whether you already have, or have chosen, the system. If yes, we implement it: assess and map it, integrate it through REST adapters on Node.js, migrate data with Python, automate the work around it including Jira, then roll out and support. If not, we do a full setup: design the TypeScript core, build the Node.js API and adapters, the PostgreSQL data layer, web and React Native apps, then run and support it. Both routes share a hexagonal core, REST APIs, audit trails, and support.Do you already have the system?or a product you have chosenYes: we implement itNo: full setupAssess and mapthe system as it runsIntegrate via RESTadapters around itMigrate datascripted and repeatableAutomate the workaround the systemRoll out, supportin phasesDesign the coreworkflow rules firstBuild the APIand its adaptersData layerschema and access rulesAppsweb and mobileRun, supportand extendSame foundations either wayhexagonal core · REST APIs · audit trail · support
The two routes share their foundations: whichever we take, the workflow rules live in one core, and every system around them connects through REST adapters.

Route one: implementing a system you already have

You run (or have chosen) a product: an HR system, a document store, Jira, a database that holds years of records. The software is fine; the work around it is manual. People copy data between screens, chase approvals by email, and rebuild the same report every month.

  • Assess and map. We map the process as it actually runs, the system’s API and data model, and who owns what.
  • Integrate through REST. Adapters on Node.js talk to the system’s API, with retries, rate limits, and logging, so it can join automated workflows.
  • Migrate data. Scripted, repeatable Python migrations with dry runs and reconciliation reports, into the system or out of the spreadsheets around it.
  • Automate the work around it. Event-driven workflows, approvals, and notifications, including Jira automation where your teams plan their work.
  • Roll out and support. Phased by team, with training and a support plan.

Signs this is your route: the system is staying, the pain is in the hand-offs, and nobody wants another tool to log in to.

Route two: full setup

Nothing fits, or the process is the product: a multi-step intake with its own roles, a client portal, an internal platform that several departments will share. We design and build it, then run it with you.

  • Design the core first. Workflow rules and permissions in TypeScript, independent of any tool (see hexagonal architecture).
  • Build the API and adapters. A versioned REST API on Node.js (see how we design REST APIs).
  • Data layer. A PostgreSQL schema with access rules and an audit trail; SQLite on devices that must work offline.
  • Apps. A web front end and, where people work away from a desk, one React Native codebase for iOS and Android.
  • Run, support, extend. Monitoring, fixes, and a roadmap for the next workflow.

Our own client project, The Expat Saas, is an example of this route: a shared relocation case for clients and their relocation managers, built as its own platform.

Often, it is both

Most real engagements mix the two: we keep the HR system and the tracker, implement them properly, and build a small platform on top for the part of the process no product covers. Because both routes share a hexagonal core and REST adapters, that mix does not create two architectures to maintain.

Want this in your systems?

Tell us about the workflow; we reply with questions or a proposal for a discovery call.

Discuss a project

More from the journal