KODESEC / PRODUCT ENGINEERING
Taking ownership.
Moving a product forward.
For about a year, I have owned development of an existing Django product: shipping features, fixing bugs, building QA and support tooling, and modernizing its infrastructure and release process.
- My role
- Solo long-term developer
- Engagement
- Approximately one year, ongoing
- Scope
- Application, infrastructure & delivery
01 / THE STARTING POINT
An existing product.
A growing responsibility.
I joined after the first version had been built. The product was an MVP with missing features, and I was hired as its solo long-term developer. Since then, I have handled the ongoing application development: new features, bug fixes, QA tooling, support integration, and maintenance.
The main Django views file already exceeded 4,000 lines when I started. Understanding how the existing code behaved was a significant part of every change. At the same time, I improved how the application was deployed and operated.
The infrastructure migration was one major milestone within that broader product responsibility.
02 / ARCHITECTURE
From repeated setup
to shared definitions.
A simplified view of the delivery model before and after the migration.
Separate deployment paths
Test, then manually copy approved code ↓
EC2 → RDS PostgreSQL
EC2 → RDS PostgreSQL
EC2 → RDS PostgreSQL
Three production environments, separate databases, and repetitive code synchronization.
A reusable platform
QA validation → promote tested images ↓
Deploy to OKE ↓
namespace
namespace
tenants
Configured tenant database schemas. Terraform defines the cloud foundation; capacity and tenant isolation still require active management.
Initially, each of the three production tenants had an EC2 instance, an RDS PostgreSQL database, and an independent GitLab repository. QA had its own repository and environment. For roughly five months, we deployed to QA, tested changes, then manually copied approved code into each production repository.
The product team chose OCI and Oracle Kubernetes Engine with operating cost and future tenant growth among the drivers. I had not worked with OCI or OKE before, so I learned the platform while implementing the move.
I containerized the application and worked on reusable deployment configuration, moving services such as Redis from server-managed systemd services into Kubernetes workloads. The migration also included transferring PostgreSQL data and object-storage contents from AWS to OCI.
03 / INFRASTRUCTURE AS CODE
A foundation
I could maintain.
I used Terraform to define the OKE cluster and worker pool, networking and access rules, private container repositories, and vault resources. The configuration also supports managed PostgreSQL with scheduled backups and a private Kubernetes API accessed through a bastion.
Separating application code, Terraform infrastructure, and Helm deployment configuration made their responsibilities explicit. Tenant onboarding became a configuration-driven workflow instead of another independently maintained copy of the application.
04 / RELEASE ENGINEERING
Test an artifact.
Release that artifact.
The move to GitHub supported a more consistent path from development to production.
- 01
Build
A release-candidate tag builds the web and worker images.
- 02
Validate in QA
The build triggers QA deployment, with migrations, rollout checks, and smoke tests.
- 03
Promote
A deliberate promotion step tags existing images without rebuilding and checks matching digests.
- 04
Deploy
Tenant deployment workflows release the selected version through a shared Helm chart.
Production receives the same image artifact that was tested in QA, instead of source files copied between repositories.
The current platform also includes repeatable onboarding and rollback workflows, health probes, configurable resource limits, and optional web autoscaling. CI includes migration checks and tests for tenant isolation. These controls support the release process; production promotion remains an intentional action.
05 / PRODUCT DEVELOPMENT
Beyond the migration.
I own the ongoing application work: building features, investigating and fixing bugs, and maintaining the existing Django product as its needs evolve. The examples below are part of that work, rather than the full list of changes made over the year.
A consistent interface across the product
I overhauled the application's UI to make its screens feel like parts of the same product. Shared visual styles and design tokens now provide a consistent foundation for navigation, typography, colors, and interface states across the application.
Testing without live Binance credentials
I built a QA mode that substitutes a simulated Binance client for the live API. It produces repeatable orders whose statuses progress over time and can inject API errors, allowing the existing order-sync workflow to be exercised without real credentials. Dummy mode requires both an enabled tenant setting and an environment allowlist entry, and the interface shows a clear banner while it is active.
Reusable support tooling
I developed a reusable Django support-bot package and connected it to n8n. The integration sends ticket information and status updates to configured webhooks, linking application support functionality to external automation workflows.
This extended my work into Python packaging and workflow integration, alongside the ongoing application and infrastructure responsibilities.
06 / MY WORKING APPROACH
AI assistance.
Engineering judgment.
I use AI as a development assistant to accelerate learning, investigation, and implementation. It helps me explore unfamiliar technologies and work through possible solutions.
I evaluate its suggestions against the codebase and the problem at hand, using my own judgment to adopt, adapt, or reject them. Understanding the changes and making the engineering decisions remain my responsibility.
07 / IN PRACTICE
Inside the workflow.
A look at the application, support flow, automation, and deployment process.
08 / WHAT CHANGED
A stronger way
to keep building.
- The application's screens gained a more consistent visual language.
- Shared release artifacts replaced manual code copying between production repositories.
- QA gained an automated deployment path with rollout checks and smoke tests.
- Terraform and reusable Helm configuration made infrastructure and tenant operations easier to maintain.
- Ongoing feature development expanded into a reusable support package and n8n integration.
This engagement has grown my ability to take ownership of an unfamiliar product, learn under delivery pressure, and improve both the application and the way it reaches its users.