October 12, 2026
At an early point in my career, I jumped onto a roller coaster of a project. A large rewrite of an in house ERP system, a 25 year old (at the time 2002 ish) rewrite of a DEC based system, rich in business logic. We were limited on technology options at that time. React, Http Fetch API, none of that existed. Development occured at a painfull pace.
This article is intended to demonstrate a real world, enterprise level application. Unlike a lot of popular social media apps, it is more representative of the day to day types of apps that the business world runs on. If you are a potential employer, then this will be a great demonstration of my skillset and the type of thinking that I bring to the table. If you are an application architect, I will cover design decisions, hopefully this will inspire new thoughts. and perhaps validate your existing practices.
My initial goal was to to apply a modern stack towards a domain space I am familliar with. I started this effort almost two years ago. It was a good way to demonstrate my skillset, keep fresh, and void boardom.
There were inherant performance problems with the original application, in large part due to ORM implementation. There were specific usage cases that would bring the application to a crawl. This was a personal paintpoint for me.
In my revised version, I have by passed the traditional ORM approach for a major bottleneck and implemented an in memory model.
Enterprise applications are notoriusly user unfriendly. Unatractive, and forged around a 'just get the job done' mentality. The fact that these applications are used for 40+ hours a week means that the user expereince has a significant impact on employee morale. Poor UX can not only be demotivating, it can impact productivity which translates into actual dollars lost.
In this project, I have completely revised some of the most used screens, revising for improved productivity. In the corporate world, it is hard to sell a project on the concept of iterations, and approach where you built, observe, and improve. There is pressure on bulding things once, on budget, on a specific timeline. This is a controlled approach, and since these apps are not consumer facing, a strong argument may be made for this methodology.
Here I am not constrained by those limitations. Am able able to apply optimized workflows given my years of experience. Given the productivity boost gained from agent assisted development, I would feel comfortable selling a project to an organzation with an iterative approach as development cycles can be dramatically reduced. Reduced development costs, an opportunity to improve user productivity, it's a win-win situation.
My mandate on the original project was to migrate the application to a newer technology stack, there was no room for attemtping improvements on the relational model. This was considered a low risk approach, and a strong argument could be made for it. The core modeling of activity between equipment (transfering and mixing fluids, etc) worked, however left room for improvement. A file based system designed around 1980 provided two decades of learing resulting in a deeper understanding of the domain model.
I was able to step outside of my comfort zone here, revisit transaction modeling, and apply what I considered a more correct object model, which I will cover in one of the related articles.
I am not stranger to code generation. I was fortunate enough at an early point in my career to have access to incredible mentors. A key lesson I learned was how to apply DSL based generators to reduce efforts related to boilerplate code. I have been doing that for over 20 years. There has been a lot of recent discussions around agentic assisted development, specifically around vibe coding. It's a hot topic.
My original efforts involved DSL based code generation for key boilerplate use cases. I wanted to write the API related pieces in both Java and Node as to demonstrate how common patterns may be applied across different stacks. A lot of effort was invested, however due to time constraints and family commitments, I did not reach all of my original goals.
Recent efforts have been more focused on agentic assisted development. This is not vibe coding, but what is starting to emerge as 'fronteer coding'. I am observing like a 10x productivity boost. I am able to experiment with providing the correct levels of context to the agent to get meaningful results.
I have organized this content into a series of articles to cover the journey of this re-architecture and development effort.
You can visit the articles via the bottom links at each page, or dive right in the topics directly here.
A brief dive into to business problem we are attempting to solve for contextual purposes, feel free to take a glance or even bypass.
Design decisions
Establishing a better role based data entry process.
Solving known performance issues.
Utilizing an visual experience to provide an optimized path for accesing inventory data.
Most apps have data that does not change often, managed by administrators. Focus here is to support those efforts with minimal effort.
Bringing visibility into a complex business process