Skip to main content

About me

·953 words·5 mins·
Dave Amit
Author
Dave Amit
Principal Architect with nearly two decades designing distributed systems and cloud-native platforms. I bring deep systems expertise, hands-on AI-assisted engineering workflows, and a track record of shipping things that actually scale. Currently writing Go and Rust, running on Kubernetes, and exploring what happens when strong architectural judgment meets modern AI tooling.
Table of Contents

👋 Hey there
#

I’m Dave Amit — Principal Architect with over 16 years of building systems that need to stay up, scale out, and make sense to whoever inherits them.

Most of my career has lived at the intersection of distributed systems, cloud-native infrastructure, and the kind of internal developer tooling that teams actually adopt. I’ve shipped loan workflow engines, Configuration-as-Code platforms, microservice frameworks, and observability pipelines — across fintech, SaaS, and consulting contexts. I care about systems that are boring in the right way: predictable under load, debuggable at 2 AM, and approachable to a new engineer on day one.

More recently, I’ve been integrating AI tooling deeply into how I engineer — not as a shortcut, but as a force multiplier. When you have enough architectural experience to critically evaluate what AI produces, you can move significantly faster without sacrificing quality or correctness. I build with it, teach teams to work with it effectively, and think a lot about where it genuinely helps versus where it confidently produces nonsense.

I’m also starting a YouTube channel around AI-assisted engineering, systems design, and real-world Go and Rust — building content for engineers who want the why explained, not just the how.


What I work on
#

Day to day, I design and build fault-tolerant platforms — the kind where things break (they always do) but the system recovers gracefully. That means distributed services on Kubernetes with Istio, data flowing through PostgreSQL and Protobuf, and a lot of time thinking about how to make complex systems simple enough that a new engineer can be productive in a week, not a quarter.

Some of the systems I’m proudest of: a state engine for dynamic loan workflows at LendFoundry, a Configuration-as-Code platform for environment reproducibility, and various internal microservice frameworks and gateways that teams actually choose to use.


🏢 How I got here
#

I started freelancing in 2006 — full-stack projects, learning by doing. Client work teaches you ownership fast. When you’re the only engineer, there’s no one else to debug production at midnight.

In 2010, I joined Alian Software as a Sr. Project Manager. I directed technical operations, managed project lifecycles end-to-end, and oversaw cross-functional teams. This is where I learned that good architecture isn’t just about the code — it’s about coordinating people, managing stakeholders, and keeping things on track.

By 2013, I joined ProT Systems as a Sr. Technical Specialist. I built an internal web framework (“Fx”) that helped teams ship faster, designed modular SaaS apps with custom OAuth flows, and spent a lot of time mentoring developers on architectural principles that actually hold up under pressure.

Since 2016, I’ve been at LendFoundry as Principal Technical Architect. Fintech is unforgiving — loan journeys are complex, uptime requirements are strict, and the systems need to be both flexible and rock-solid. I’ve built workflow engines, championed Kubernetes and Istio adoption, and created tooling that makes deployments repeatable and debugging less painful.

Most recently, I’m spearheading LendFoundry’s AI enablement track — end to end, from discovery through production. That means evaluating where AI genuinely moves the needle (and where it doesn’t), designing the infrastructure to support it safely, integrating AI-assisted workflows across the engineering lifecycle — QA, code review, SRE, documentation — and helping the team build the intuition to work with these tools effectively rather than just react to the hype. This has become one of the most interesting problems I’ve worked on: it’s not just a technology question, it’s an organizational and systems design challenge at the same time.


🚀 Open source
#

I’ve taken a lot from the open source community over the years. It’s time to put something back.

bs (The No Bullshit Build System) is my current main project — a build orchestrator written in Go that separates intent from implementation. You describe what you want; it handles the plumbing. More on this in the devlog.

ProjectC is a Configuration-as-Code system designed to be extensible across frameworks, starting with Go and Rust SDKs. The goal: rich, composable, reproducible configs at scale.

ProjectB is a CI/CD-inspired artifact processing platform — less “pipeline” and more “flexible factory.” It sits at the intersection of developer tooling, automation, and reproducibility, which is basically my favorite intersection.


Stack
#

Currently writing: Go, Rust, JavaScript Infrastructure: Kubernetes, Istio, Protobuf, PostgreSQL, Dgraph Past lives: Python, .NET (C#, VB.NET), Java, Node.js — enough to bring perspective, not enough to claim expertise in all of them anymore.


🧭 Engineering philosophy
#

I think software should be boring in the best possible way — predictable, testable, and solid under stress. A few principles I keep coming back to:

Design for failure, because distributed systems will fail. Build for clarity and reproducibility, because you’re always writing code for the next person (and “the next person” is often future-you at 2 AM). Prefer simple tools over clever abstractions. Automate the boring stuff. Document the confusing stuff.

None of this is original. But the teams that actually do it consistently tend to sleep better.


⛺ Outside the terminal
#

When I’m not writing code, I’m usually somewhere without cell service. Trekking and mountaineering are how I reset — forest trails, high-altitude rock, anywhere quiet and remote.

I play a lot of From Software games — Bloodborne, Dark Souls, Elden Ring. They’re humbling in the same way distributed systems are: you will fail, repeatedly, and the only way forward is patience and pattern recognition. Good things take time.

I’m also learning Japanese. Just started N5, still early, but going strong. いつか日本で登山したい — someday I want to go hiking in Japan.


📬 Get in touch
#

Thanks for reading. If you’re building something hard and interesting, I’d love to hear about it.


comments powered by Disqus