træct.dev

Hire me

Complexity is just structure waiting to be found.

Open for new engagements starting September 2026.


What I actually do

I work as a one-person engineering team. I take a system from nothing to running in production — the infrastructure, the app, the data, the AI — and hand it over with documentation, tests, and nothing locking you in. If a job genuinely needs more hands, I lead the team rather than join one.

Usually it’s one of three things:

  • AI built on your own data — answers that point back to a real source, not guesses.
  • A software product taken to production — accounts, billing, the admin side, the lot.
  • Infrastructure that holds up — deploys, security, and monitoring you can actually trust.

Open source where it counts, hosted in the EU, domain-driven where the domain matters, Lean where speed matters. I don’t lock you into anything.

Currently / recent:

  • A national government’s policy-signal platform — full-stack + RAG + an Apache Iceberg lakehouse, EU-sovereign serverless (under NDA)
  • A multi-tenant energy-simulation SaaS — auth, billing, usage metering, R simulation engine (under NDA)
  • Forgitry — EU-sovereign git forge (Go, in active development)
  • Zettelgeist — portable markdown spec format
  • eurlxp — EUR-Lex Python parser
  • Greek government data API toolkits (Diavgeia, RAE, ELSTAT, KIMDIS, TED, Mitos)
  • An open-source energy quadratic-optimisation toolbox (in progress)

What I don’t do

  • Frontend-polish gigs. I do full-stack, but if you mostly need a designer who codes, I’m not it.
  • Pure data-science modelling. I integrate ML into systems; I’m not your statistician.
  • “Just port us to AWS.” If the reason is “everyone does,” I’ll push back. That’s either a feature or a deal-breaker for you.
  • New builds on Microsoft stack. I’ll touch Active Directory or Azure where necessary — usually to interface with or migrate off them — but I don’t build new systems on Microsoft infrastructure. Different defaults; if that’s what you want, you’ll be happier with someone who does.
  • Body-shop staffing. I work on problems, not seats.

What you should expect from me

  • Pushback when it matters. If your plan is shaped wrong, you hear it in week 1, not week 8. Saving you from your own brief is sometimes the most valuable thing I do.
  • A real recommendation, not a fence-sit. I’ll think through the angles — that’s the work — but you get a clear call at the end. “It depends” is fine when it genuinely does. Most of the time it’s a cop-out and I won’t hide behind it.
  • No vendor scripts. I don’t take referral fees or kickbacks from any cloud, SaaS, or tool. What I recommend is based on what fits — nothing else.
  • A short answer when there is one. If the real problem is a 3-day fix, it’s a 3-day engagement, not a 6-week one with padding.
  • You get me. Not “Mo for the first month, then a junior nobody told you about.” One person, one inbox, one set of standards.

How engagements typically go

Three shapes. Happy to discuss variations.

1. Architecture & code review intensive — 1–2 weeks, fixed price. I read your code, talk to your team, produce a written report with a decision tree of options. Useful when you’re not sure if the current direction is right, or before committing to a big build.

2. Build engagement — 6–12 weeks, scoped, fixed-price option available. We agree the deliverable up front, I build it, hand it over with documentation and tests. Examples: a sovereign deployment of a system, an end-to-end data pipeline, an internal platform, an optimisation engine.

3. Senior engineering retainer — 2–3 days/week, minimum 3 months. Ongoing technical leadership without you having to hire a full FTE. Architecture, code review, mentorship, unblocking hard problems.

How working with me actually starts

  • Intro call (free, 30 min): no pitch, no slides — just a conversation. Email a rough idea or “I’m stuck on X” and we set up a call if it makes sense.
  • Paid scoping (short, fixed price): I read your code, talk to your team, produce a written brief — what the real problem is, your realistic options, what I’d recommend with trade-offs. You own that brief regardless of what happens next.
  • Engagement proper: milestone-based. If at any milestone you’d rather stop, we stop, and you pay only for what’s been delivered. I’d rather lose an engagement early than drag one past where it’s earning its keep.

Rates and scoping fee: discussed in the intro call.

Why opinionated about open source and lock-in

Two reasons.

Practical: vendor lock-in is a slow tax — paid in renewal price hikes, migration projects, and the loss of optionality. Open source by default protects your future self.

Personal: I’ve watched too many teams discover that the platform they bet on quietly changed the rules. I don’t want to be the engineer who put them there.

That said: I’m not a FOSS zealot. If a managed proprietary service is genuinely the right call for your context, I’ll say so. The point is to think about it, not to default.

How to get in touch

Email: mo@traect.dev — a short brief, rough idea, or “I’m stuck on X” is fine. I read everything.