Opening
I spent nearly ten years as an internal system engineer in a non-IT company. I occasionally hired people for specific phases, but in most periods I was the primary engineer responsible for architecture, implementation, and operation.
That responsibility changed how I evaluated design decisions. I was not selecting architecture for an ideal team setup. I was selecting architecture that I could sustain over time with limited coordination bandwidth.
Previous Career Model
Before that period, I had experience in contract engineering services and large-team projects. In those environments, a common model was to split screens across engineers and let each part progress in parallel.
This model works well when a project has enough people. It scales horizontally because many engineers can develop and review different screens at the same time.
This was not inherently flawed architecture. It was a coordination model optimized for scale.
I am not presenting that as criticism. It is a structural observation about team size and architecture fit.
The Scaling Problem for One Person
When one person builds the whole system, the same distributed screen model becomes inefficient. Even without a team, the architecture still carries coordination overhead between screens, flows, and states.
Context switching becomes a direct cost. Each screen has slightly different assumptions, and reconciling those assumptions repeatedly slows implementation. Over time, flow consistency also drifts because each local decision is made in isolation.
In practice, each screen tended to carry isolated logic, and there was no strong shared lifecycle boundary. Without that boundary, architectural consistency depended entirely on discipline rather than structure. As screens accumulated, cross-screen behavior drift became harder to control.
Early Independent Experiments
Outside company work, I also took small system contracts. In those projects I started from PHP, Smarty, and jQuery, with a practical goal: unify screen flow and behavior across all pages as much as possible.
I was not trying to invent a new framework. I was trying to keep workload survivable.
At that time there were already excellent PHP frameworks, and I did try some of them. I do not remember the exact reasons I rejected each option. What I clearly remember is that, with my knowledge at that time, they felt difficult to adopt when I needed to design with confidence and deliver the required scale by myself, including the learning cost.
That conclusion was about my requirements and constraints at that time. It was not a claim that those frameworks were inadequate for business applications in general.
Skill Limitations at That Time
My web application experience was limited in that period, not only on the frontend side but across web application design itself. Most of my earlier work was open-system development with VB, C#, C++, and Oracle-based databases.
I had also worked on server-side programs, and I had participated in ASP.NET projects, but mainly on backend responsibilities. I did not yet have broad experience designing and operating web applications end to end.
My frontend skill level was close to beginner, and I also had very little awareness of broader tooling ecosystems.
Webpack may already have existed in practical use, but I was not aware of it when I made those decisions. That gap mattered, and I do not want to rewrite that history as if I had clearer technical visibility than I actually did.
The Improvised Architecture
I ended up creating modular components, connecting them through PHP, and manually standardizing behavior patterns. In retrospect, this was primitive.
Still, productivity improved. Systems reached a reasonable size for one person to build and maintain, and implementation speed became better than my earlier attempts. It was a practical approach under constraint, not a polished architecture strategy.
PHP 7 Impact
PHP 7 improved day-to-day development for me, especially through type declarations. Stronger typing reduced ambiguity and made code review easier.
However, frontend pressure remained. The jQuery-based side hit limits quickly as state combinations increased. Event handling became scattered, state mutation stayed implicit in many paths, and keeping behavior consistent across screens became progressively harder.
Discovering TypeScript
When TypeScript started to gain visibility, static typing immediately made sense to me. At the same time, adopting it required transpilation and a build step, which was a practical change from the PHP and jQuery workflow I had been using.
The friction was not philosophical. It was operational. A new toolchain changed how I worked every day.
.NET Core 3 Decision
Around the time .NET Core 3 appeared, I decided to move to that stack. That decision became a turning point and the beginning of what later evolved into Cotomy.
Given my language background, returning to a more explicit type system fit how I thought. I had felt ongoing discomfort with dynamic typing in PHP for larger internal systems.
The build process also had a hidden benefit for me. It forced pauses. It forced reflection. It caught mistakes before runtime and added structural discipline to development flow.
That shift was less about language preference and more about changing how decisions were validated while building alone.
Still, C# is my favorite. I admit this may be personal taste, but the code just feels more elegant to me.
Closing
The early architecture that led to Cotomy was very different from the public version today.
In future articles, I will cover the earliest design attempts, the mistakes, the architectural pivots, and why certain structural boundaries exist in its current design.
Development Backstory
This article is part of the Cotomy Development Backstory, which traces how Cotomy’s architecture emerged through real project constraints.
Series articles: Building Systems Alone, Early Architecture Attempts , The First DOM Wrapper and Scoped CSS , API Standardization and the Birth of Form Architecture , Page Representation and the Birth of a Controller Structure , The CotomyElement Constructor Is the Core , Dynamic HTML Boundaries in CotomyElement , Reaching Closures to Remove Event Handlers Later , and The Birth of the Page Controller .
Next article: Early Architecture Attempts
