> I am Panos,
a software engineer and systems architect in Athens, Greece. For 20+ years I've done one kind of work: replacing the foundation of a system while the building stays occupied, customers and all.
That kind of work is rarely small or palatable. It's the scope a team would normally split across half a dozen people for half a year, and I take it on whole. Sometimes that means heads-down, delivering it alone. Sometimes it means joining the team and building it with them. Sometimes it means owning the architecture: setting the direction everyone else builds from there on. The role fits the problem; the appetite for scope doesn't change.
I work through my consulting firm, NEFELOMA.
You may have used software I've worked on if you've:
- secured your organization's PKI via Smallstep's open source, on-prem, or hosted products.
- deployed on Fly.io.
- run a site on Pagely's managed WordPress hosting (acquired by GoDaddy).
- ridden a Spin scooter or e-bike.
Some shapes of my work:
Memory-backed tenant cache
Recurring production incidents traced to Postgres being hammered on hot-path reads. The dataset was small enough to hold in memory and would stay that way, so I held it there, and solved invalidation by driving updates straight off the Postgres replication log. 300k requests a second on two commodity vCPUs. The incidents stopped.
Backend platform
A distributed TypeScript platform, ported to Go and made the substrate every new backend service now starts from. The rewritten data access layer was lean enough that each small Go pod retired five large TypeScript ones; the platform got cheaper to run as it grew.
gRPC contract management
The services in a distributed stack had drifted onto incompatible gRPC contracts. I
built one repository as the source of truth for every protobuf definition, with a
git-based pipeline that generates each language's client library and publishes it to
its own repo; consumers pull them as ordinary git dependencies, with no
registry to run. A service now ships by committing its proto, and every caller has a
matching client on the next CI run.
Service library
One import and a few lines, and a new service traces, measures, logs, and behaves like every other one in the system. It's the in-house library that decides how Go services are structured, instrumented, and tested. Nobody reasons over observability anymore; the cost is conformity, which was the entire point.
IoT vehicle abstraction layer
The fleet was live: a mix of vehicle hardware, each speaking its own protocol, and a Rails backend wired into every one of them. It didn't have to be. I decided the backend should speak a single language regardless of what was on the road, and built a set of Go servers, one per protocol, each translating a vehicle's native chatter into it. Then I refactored Rails to speak only that, blind to the hardware underneath. All of it landed without taking the fleet down.
Developer experience CLI
Every engineer develops against their own Kubernetes environment. The old tool made you tear down the whole loop to change which version of a service you were running, so trying a colleague's branch meant stopping your own work and starting over. I rewrote it in Go from scratch to make switching live: name a branch, and it applies at once. Someone in Slack wants their branch tried? Send the name. No checkout, no clone, no restart.
On the way past
I fix what I trip over, asked or not.
- A production query taking 75 seconds. I rewrote it around merge anti-joins and a partial index; it returns in 400ms.
- A database with no answer to how long its records should live, so it grew without bound. I set the retention policy and built the GC. In two months it cleared 41.8 million rows from each of the two heaviest tables (280 and 897 million rows), and it keeps ticking every minute.
-
Go services getting OOM-killed under load, because the runtime couldn't see the
container's memory limit. Kubernetes can't express "90% of the pod's limit" as a
value, so I added an entrypoint shim that computes it and exports
$GOMEMLIMITbefore the binary starts. The kills stopped.
$ The work I take on is usually the hard-to-staff kind: the migration nobody wants to own, the system that has to change without going down, the architecture that needs deciding. If you think there's a fit here, tell me what you're building or fixing at [email protected].