Sheet 01 General arrangement Scale: 8 years @ 1:1 · Rev. 2026

This is the system I keep being hired to build. Click any part of it.

Eight years of Python backends, trading pipelines, Kubernetes clusters and the monitoring around them — for payments, energy markets, equities, retail and logistics.

Open to contract work & full-time roles · Remote, UTC+3

Dwg. 01 — Reference architecture Select a zone for detail

Zone

—

Where this came from

—

Tools

Sheet 02 Scope of work Five items · priced per engagement

What you can hand me, and what comes back

Every engagement below has ended with something you can run without me. That's the point of writing the deliverables down.

Schedule of services — Rev. 2026
Item	Scope	Deliverables	Engagement
A	Backend & API systemsThe services your product runs on, designed for the load you actually have. Sync or async, REST or event-driven.	Running services Test suite API documentation Handover notes	Project or fractional
B	Cloud, containers & CI/CDGet off manual deploys. Containerise the app, write the Kubernetes manifests, wire the pipeline, add the monitoring underneath.	Repeatable deploys K8s configuration Pipeline Runbook	Project 4–10 weeks
C	Data & trading pipelinesScheduled jobs that collect data, evaluate it and act on it with nobody watching — plus the alerting that catches a bad run.	Pipeline on AWS or GCP Simulation stage Alerting rules Health dashboard	Project or retainer
D	Monolith to microservicesFor a system that has outgrown itself. I find the real seams, split along them in stages, and keep it serving traffic throughout.	Migration plan Extracted services Rollback path Load test results	3–6 months
E	Architecture reviewOne week reading your system and telling you the truth about it. The cheapest way to find out whether you need the other four.	Written report Risks, prioritised Cost/effort estimates A call to walk it through	1 week fixed fee

Not sure which line you need? Start with item E. If the review says the answer is nothing, that's a good week's money saved.

Sheet 03 Built work Selected · 2017–2025

Five systems, and what each one taught me

Two clients are under NDA and named by sector. The rest are named.

ClientNDA · energy

SectorWholesale power, ERCOT

PeriodJan 2024 – Feb 2025

RolePython developer

StackPython, GCP, GitHub Actions, SOAP, Docker, Bash

An automated trader for the Texas power market

ERCOT settles electricity in intervals that don't wait for anyone to be awake. The platform I worked on places and manages orders against that market automatically, which changes the engineering problem: correctness stops being the whole job, and noticing is half of it.

I built the services for market data collection, order placement and system monitoring, and designed the trading pipeline to run as GCP container batch jobs orchestrated from GitHub Actions. Then I instrumented health metrics across every stage and aggregated them into performance insight, so a degraded run announced itself rather than being discovered later in a settlement report.

A pipeline nobody is watching needs to be louder than one that somebody is.

ClientNDA · fintech

SectorUS equities

Period2023 – 2024

RolePython developer

StackPython, AWS, GitHub Actions, Docker, Bash

Keeping an equities trading platform on its feet

An automated platform trading US stock markets, where the cost of a service being down isn't an error page — it's a market window you can't get back. My job was the AWS services behind the trading path and keeping their operation uninterrupted through the session.

Alongside that I built automated monitoring for the daily trading jobs, with alerting tuned to catch a run that had gone anomalous rather than one that had merely finished slowly. Knowing the difference is most of the work.

ClientVgang

SectorRetail / dropshipping

PeriodJan 2022 – Apr 2023

RoleFull-stack developer

StackPython, Django, Golang, Kubernetes, Docker, Nginx

A retail platform that speaks Shopify

Vgang connects suppliers and sellers across Shopify and Instagram into one shopping experience, which means most of the engineering is other people's APIs, other people's rate limits and other people's downtime.

I built and ran the Kubernetes cluster the platform sits on, automated releases end to end with GitLab CI/CD so deploying stopped being an event, and wrote the microservices handling Shopify integration and data exchange — in Python where the domain was complex and Go where the path was hot.

Integrations fail constantly. Design for it and the platform feels stable anyway.

ClientZibal

SectorPayments

PeriodNov 2020 – Jul 2021

RoleSenior Django developer

StackPython, Django, Kubernetes, MongoDB, Redis, Celery, Prometheus, Grafana, ELK

Taking a live payment gateway apart, carefully

A payment gateway is the least forgiving kind of monolith to modernise: there is no maintenance window anyone will accept, and every mistake is somebody's money.

I drove the initiative to decompose it into microservices, splitting along real domain seams rather than convenient ones. Along the way I Dockerised the whole application so environments stopped differing, authored the Kubernetes manifests behind scalable deployments, and put Prometheus and Grafana in place so that reliability became a number instead of an opinion.

Nobody signs off on a migration they can't watch. Ship the dashboards first.

ClientRahpa

SectorLogistics / consumer

PeriodDec 2017 – Nov 2020

RoleFull-stack developer

StackPython, Tornado, Django, MongoDB, Redis, Celery, Kubernetes, Prometheus, Grafana

Three location-based products, from backend to handset

My longest engagement, and the one where I built the widest slice: async Tornado backends for real-time fleet and location tracking, Angular dashboards on top, and mobile apps in Kotlin and Flutter for the consumer side.

It's also where the infrastructure habits started — Docker and Kubernetes for deployment, Prometheus and Grafana for tracking behaviour under real load, unit tests and GitLab CI so that three products could be maintained by a small team without breaking each other.

Also delivered

2023 – 2024Backend services and several educational games for university students — Flask and MongoDB, load-tested with LocustBrain Shuttle

2021 – 2022A hosted store builder in the Shopify mould — Django backend, Vue and Angular front ends, ELK, GitLab CI/CDPyango

2018 – 2020Selenium data-collection pipeline and a real-time ping monitoring dashboard in DjangoNDA

Sheet 04 Details Own work · not client-commissioned

Things I built to learn the hard part properly

Sandboxing untrusted code, leader election, metaprogramming — the parts you can't really claim until you've implemented them once.

Platform

NeetCoders

A coding practice platform in the spirit of LeetCode. Submissions execute inside a Docker-based sandbox and arrive through RabbitMQ, so untrusted code never touches the application process.

Django · RabbitMQ · Docker sandbox · Next.js · asyncio · S3

Distributed systems

CoffeeChat

A chat system built to scale sideways: etcd handles leader election and real-time routing between nodes. Written mainly as an excuse to implement consensus rather than read about it.

Go · etcd · leader election · WebSockets

Pipeline

SmartTrader

A Forex pipeline on AWS split into four stages — signal generation, evaluation, simulation, execution — so a strategy has to survive simulation before it is allowed to spend anything.

Python · AWS · S3 · Athena · Step Functions

Open source

File-Based ORM

An ORM whose backing store is the filesystem, written to find out how far Python metaprogramming can be pushed before the result stops being readable by anyone else.

Python · metaclasses · descriptors

Product

MasterYourCourses

A microservices-based learning platform with chat, online exams and calendar management. I also teach Python, Go and JavaScript on it, mostly to teenagers and career switchers.

Microservices · Python · real-time chat · S3

Writing

76 posts on DEV

Working notes on relational database design, SQL, Python, and the financial concepts sitting underneath the trading work — written as I learn them, which is the only way I trust that I have.

dev.to/bshadmehr · databases · sql · python · go

Sheet 05 Specifications Depth noted against each line

The toolkit

Listed honestly: what I reach for daily, and what I've used enough to be useful with.

01 — Languages

Python8 years, primary
Golangproduction services
TypeScriptfront end
JavaScriptfront end
SQLdaily
Bashtooling, CI

02 — Application frameworks

Djangoprimary
FastAPIprimary
Flaskprimary
Tornadoasync, long-lived
Sanicasync
Celerybackground work

03 — Infrastructure

Dockerevery project
Kubernetesbuilt and operated
GitHub ActionsCI/CD
GitLab CICI/CD
Terraforminfrastructure as code
Nginxedge, routing

04 — Cloud

AWS Lambdacompute
AWS S3storage
Athena & Glueanalytics
Step Functionsorchestration
ECScontainers
GCP Batchscheduled jobs

05 — Data

PostgreSQLrelational
MySQLrelational
MongoDBdocument
Rediscache, locks
DynamoDBkey-value
InfluxDBtime series

06 — Observability

Prometheusmetrics
Grafanadashboards
ELKlog aggregation
Sentryerror tracking
Locustload testing

07 — Interfaces

Next.jsReact
Vueapplications
Angulardashboards
Kotlin / Fluttermobile, prior work

08 — Architecture

Microservicesled a migration
Event-drivenqueues, workers
Hexagonalports and adapters
Serverlessjobs, pipelines
Layereddefault for small teams

Sheet 06 General notes Read before construction

Note 1 — assume it will fail at 3 a.m. and design backwards from there.

Note 2 — a system you can't observe is a system you're guessing about.

Note 3 — the fastest way to find out whether you understand something is to teach it.

How I work

I started with Python and JavaScript, drifted into Go and infrastructure, and ended up spending most of my career on the unglamorous half of software — the part that has to still be running tomorrow.

That shapes the order I do things in. I want the failure modes before the feature list. I containerise early, because environments that differ are a category of bug you can simply decline to have. I put metrics in from the start rather than after the first incident. And I write tests for the paths that would cost real money if they broke, which is a shorter list than "everything" and a much longer one than "none".

I've worked as the only backend engineer on NDA trading systems and inside cross-functional teams at product companies, so I'm equally comfortable owning a domain end to end or joining an existing codebase and respecting its conventions instead of rewriting them. For a few years I've also taught Python, Go and JavaScript to beginners at Master Your Courses — and I write up what I learn as I go, currently 76 posts on DEV.

I'm based in Türkiye on UTC+3, work remotely, and overlap comfortably with European hours and US mornings. Right now I'm taking on new projects and open to full-time roles.

Exploring relational databases: concepts and applicationsDatabase · SQL ↗ Understanding correlation in financePython · Data ↗ A dive into fundamental financial statementsFinance ↗ All 76 postsdev.to/bshadmehr ↗

Sheet 07 Issue Status: available

Tell me what's breaking, or what doesn't exist yet

info@bshadmehr.me

I read everything and reply within a day — including to say no when I'm not the right person for it.

Emailinfo@bshadmehr.me LinkedIn/in/bshadmehr ↗ GitHubbahmanshadmehr ↗ DEV76 posts ↗ Curriculum vitaePDF ↓

Issued for construction

What you're building, in a sentence.
Where it's stuck — or what doesn't exist yet.
The stack, if there already is one.
Timeline, and whether this is a contract or a role.