AI Translated Document

This document was translated using an AI translation tool.
Due to the nature of AI translation, some sentences or terms may be interpreted differently from the original intent.
There may be mistranslations or inaccuracies, so please refer to the original text or consider additional review if accuracy is critical.
Your suggestion for a better translation would be highly appreciated.

Original Document in Korean

Proof of the Possibility of a One Man Framework¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
Draft: November 2025 / Revised: December 2025

[Interpretive Note] This article is not simply to show that “one-person development & operating is possible,” but to illustrate what results from making structural decisions that reduce the effort required to manage and operate a system.

Executive Summary¶

This document presents the actual results of a system that structurally minimizes the effort required for one-person development, operation, and management.
It is based on a real case where a commercial system handling 440,000 transactions and 5.3 billion KRW over 12 months was stably operated by a single person.
The operational limit is determined not by scale, but by the number and complexity of management points.
Repetitive tasks should be automated and authority delegated, so the developer only handles exceptional cases.
More important than responding to failures is designing so that failures do not occur.
Optimization is not just about reducing costs, but about structural simplification to minimize the impact of changes.
Tool selection should be based on business context and actual operating conditions, not trends.
The conditions for possibility are clear: fewer than 30 developer intervention errors per year, and total management overhead under 24 days.
This is the cumulative result of architectural decisions that prioritize robustness above all.

Proof¶

As of December 2025, it has already been in operation for over a year. Proof complete!

Logically, to prove the possibility, you only need one real-world case. So the proof is very simple. But what readers will really wonder is under what conditions and at what scale can it be operated?

First, what scale?

To be clear, this is about how large an IT system a solo developer can operate live— it is absolutely not about growing a business. The system was already in operation for a long time and had many customers.

I got involved three years ago, rebuilt a nearly failed next-gen system, completed it, migrated to AWS, and took over operations. Attracting customers is not a developer's job.

This system processed 440,000 transactions and 5.3 billion KRW in total from November 2024 to November 2025.

The following is a summary of the operating environment; details are described below. - Scale: 440,000 transactions and 5.3 billion KRW in 12 months - 500GB annual log data - AWS infrastructure - Single DB using AWS Aurora - Standard structure: load balancer + redundant web server + DB - Vue 2.x, Java 17 SpringBoot 3.0 JPA, Node.js for some high-performance tasks - Fewer than 30 errors per year requiring developer intervention - Passed ISMS (Korean government-mandated information security certification) audit two years in a row - Very simple security model - Optimized design/development downsized web server spec (16GB → 4GB) - Optimized design/development downsized DB data (80GB → 15GB) - Java max CPU usage under 30% at burst - Java max RAM usage under 75% at burst - Simple self-made CLI tools for automating repetitive tasks

The Key Is Not Scale, but Management Overhead¶

What matters more than system size is minimizing the time and effort required for management. If there are few management points even at scale, solo operation is entirely possible. Develop robustly and reliably, automate and tool repetitive tasks as much as possible, delegate authority appropriately, and operate so the developer only needs to care about exceptional cases.

Make Tools and Delegate Authority¶

Don't handle repetitive operations, data corrections, or monitoring yourself—make tools anyone can use. If you delegate these tools to trusted colleagues or operators, the developer can focus on development and improvement.

If a trusted operator uses them, the tools can be rough or risky, meaning you can have fewer exception handlers or safety devices. The tools become simpler, operators gain more freedom, and more exceptions can be handled.

Make Failure Impossible¶

Design from the start to eliminate defects as much as possible. This is often misunderstood as identifying failure points and preemptively handling them with auto-recovery, workarounds, or alarms. But that's not realistic.

Honestly, in most cases, auto-recovery or workarounds are wishful thinking. These basically mean double the development/operating cost, and reliability issues from complexity.

This system is a shopping mall with free shipping benefits for some users. Before my redesign, free shipping eligibility was calculated by order count within a period. Naturally, exceptions abounded—people who should or shouldn't get it did or didn't, and all the burden fell on the developer.

So I changed the mechanism to make such errors impossible. Promotion periods and targets are clearly recorded in the DB, and a hidden shipping coupon ledger is kept in the DB, so errors from indirect calculation by period/order count are fundamentally blocked. This reduced management overhead by about 30 days per year.

Sometimes optimization is misunderstood as just continuously removing unnecessary computation, excessive resource use, or duplicate data. But optimization is not just about "cutting."

Of course, reduce unnecessary usage, but if needed, actively use duplication.

Naturally, order info has an 'order status' column. Order status explains a lot, so it overlaps with isPaid, canDrop, isDrop, needShipping, sentShipping, etc. Still, I declare and manage all as Boolean variables. By gathering the few status-changing points into a separate code file and managing them strictly, all conditional behavior in the system can be controlled uniformly. If you use order status as a code for query conditions, a small change can trigger many operations. By specially managing main status change functions, the propagation of signals is simple and clear, and side effects are fundamentally blocked. DB index performance is a bonus.

Choose the Right Architecture¶

In complex business environments such as e-commerce and logistics systems, simply adopting RESTful APIs because they are industry trends or standards can lead to serious inefficiency and structural risk. RESTful architecture is fundamentally optimized for distributing and sharing static documents, based on constraints like statelessness, cacheability, and uniform interface. While these are advantageous for efficient information distribution, they are not suitable for business systems where real-time state changes and complex transactions are frequent.

Therefore, for systems where state changes, transactions, and complex rules are core—such as e-commerce, logistics, or education/learning management—a command-based API design optimized for each screen (or business scenario) is much more effective. A command-based API does not simply list CRUD endpoints, but provides clear commands (e.g., order approval, payment processing, inventory reservation) tailored to actual user actions and business flows. This allows multiple state transitions and transactions to be handled atomically in a single API call, with the server clearly responsible for business logic, data consistency, and security. As a result, the client is freed from complex state management or compensation logic, and the overall system reliability and maintainability are greatly improved.

Command-based API design offers several advantages: First, API design tailored to real business flows clarifies communication between client and server and allows flexible response to changing requirements. Second, atomicity of transactions and data consistency can be guaranteed on the server, greatly reducing exposure to intermediate states or security vulnerabilities. Third, network call counts are minimized, improving performance and reducing failure points. Fourth, complex domain models and entity relationships can be managed effectively on the server, greatly reducing client implementation complexity. Finally, command-based APIs make it easier to handle various exceptions in real operating environments, and root cause analysis and recovery are much simpler when failures occur.

Use Appropriate Tools¶

You don't have to build everything yourself. Actively use proven open source, cloud services, and automation tools to reduce development and operations burden. Amazon's DB, log management, alarms, and web server monitoring are good. With external tools, you can even get emergency calls.

But don't use only external tools.

If you do Java, you might think you must use CI/CD and Jenkins. That's uncritical thinking, and using a tool doesn't absolve you of responsibility. Ironically, people install CI/CD tools for continuous integration/delivery, but rarely review integration or deployment strategies. A tool is just a tool. Before deciding what to install, identify the problem and decide how to handle it. This system processes 5 billion KRW a year, but doesn't do weekly deployments, and there's no QA team for nightly builds. Major patch deployment intervals are almost three months. In this situation, a simple automated CLI tool to prevent human error in deployment is enough. I wrote this in Node.js. It opens SSH, uploads files, makes API requests, and runs bash scripts. That's it, but it works great, needs no extra server, and doesn't require managing features or settings.

Before I joined, deployment involved manually taking down machines from the load balancer, uploading, and applying changes. With this simple Node program, annual management overhead is about one day. Jenkins would be 20 days, manual load balancer/file upload about 10 days.

A tool is just a tool. Before deciding what to install, identify the problem and decide how to handle it. This system processes 5 billion KRW a year, but doesn't do weekly deployments, and there's no QA team for nightly builds. Major patch deployment intervals are almost three months. In this situation, a simple automated CLI tool to prevent human error in deployment is enough. I wrote this in Node.js. It opens SSH, uploads files, makes API requests, and runs bash scripts. That's it, but it works great, needs no extra server, and doesn't require managing features or settings.

Before I joined, deployment involved manually taking down machines from the load balancer, uploading, and applying changes. With this simple Node program, annual management overhead is about one day. Jenkins would be 20 days, manual load balancer/file upload about 10 days.

Robustness¶

A robust system doesn't just mean few failures, but that the whole service doesn't collapse in unpredictable situations. But in reality, what developers and architects can implement is different. For example, there are no computers that work at 400°C. So a system that never fails in any situation is a mirage.

True robustness needs three things: 1. The planned business flow works normally. 2. Even with unplanned actions, the system doesn't stop. 3. When unplanned actions occur, the cause of failure is clearly indicated.

Any developer with 5+ years' experience feels this. A compiler/runtime that pinpoints syntax errors is trustworthy. Tools that point to the wrong place waste time.

People work effectively with trustworthy tools. If the system isn't robust, you can waste dozens of days a year just finding error causes. If it's robust, 99.9% of users feel no problem, and the 0.1% can be handled quickly.

Conclusion: When Is It Possible?¶

Conditions for realization

In one sentence:

"Fewer than 30 errors per year requiring developer intervention, average 1 day per error. Total annual management overhead under 24 days."

But that's a result; to achieve it, you must prepare in planning/design/implementation/operations: 1. Understand the business precisely. Not just the dev team—every department must know their work and avoid confusion. No unnecessary development/operations. 1. Choose an architecture that fits the business and develop to minimize maintenance (money+time+effort+complexity). 1. Prioritize 'robustness' in planning/design/implementation/operations. 1. Avoid tools that are too complex for their value. Choose tools for maximum cost-effectiveness. 1. Have a competent operations team. That is, people who can use somewhat risky tools appropriately. 1. Don't be swayed by potential maximum value. Focus on current ROI.

Author¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University