ERIK DREYER · LIQUID SOFTWARE LLC
Hi, I’m Erik. I have a knack for guiding AI-enabled teams to eliminate the slop and build production-quality systems. I work alongside your engineers to make it happen.
Engineer. Architect. Fractional CTO.
I’ve cofounded multiple startups and led a payments team at Toast that processed more than $10 million a day.
Fluid thinking. Solid engineering.
FOLLOW THE THREAD01 / FIND YOUR STARTING POINT
Sometimes you need someone to help steer. Sometimes you need someone in the code. Often, you need both. You get both with me.
I can help you decide what deserves attention, work through technical decisions with your engineers, and get into the code when that’s what the work needs. I also pay attention to what’s slowing the team down and help clear the way.
Your engineers shouldn’t have to untangle unnecessary abstractions or check whether an API actually exists in every review. I work alongside them to give agents better context, keep changes focused, and verify the behavior that matters. We examine the results together and refine the guidance where it falls short.
I work across the full software lifecycle, from figuring out what needs to be built through deployment and production monitoring. That means thinking about how the software will be tested, operated, and changed while we’re designing and building it.
02 / AI, WITH ENGINEERING JUDGMENT
Unnecessary abstractions. Missed requirements. Code that looks convincing until someone has to maintain it. Systems that appear to work while hidden bugs quietly put real money at risk.
I’ve developed a set of guardrails that make my engineering expectations explicit to the agents I work with. They need to understand the existing code, keep changes focused, and verify the result against the requirements. When something is unclear, I expect them to say so.
These are the kinds of details I work through with your engineers. We adapt the guidance to your software and examine what the agents produce.
Start a conversationYour team’s judgment remains essential: the instructions need to reflect it, and the resulting code still needs to earn their trust.
03 / EXPERIENCE THAT TRAVELS
I’ve been the cofounder building the first product and the engineering leader working at scale. Each calls for a different kind of judgment.
STARTUP COFOUNDER
I’ve cofounded multiple startups and know what it takes to get the first product off the ground. That means being hands-on, making practical tradeoffs, and adjusting as the business learns.
At the beginning, knowing what to leave out matters as much as knowing what to build.
ENGINEERING LEADERSHIP · TOAST
At Toast, my payments team processed more than $10 million a day. The stakes make correctness and reliability very concrete.
I bring that attention to the consequences of software decisions.
DEVELOPING PEOPLE
Across HomeAway, Curbee, and Toast, I’ve approached leadership by trusting engineers and making sure they have the direction and support they need. Sometimes that means protecting their focus. Sometimes it means bringing people together to work through a problem.
Helping engineers grow is part of that responsibility. At HomeAway, I co-led a six-week graduate onboarding program. Across my teams, I’ve also mentored people in software practice and the working relationships that become increasingly important as they take on more responsibility.
Selected experience from my career as a founder and employee.
04 / RECENT WORK
A language-learning app of my own, a healthcare product for Spindle Health, and some code I’ve shared along the way.
MY OWN PRODUCT · iOS
My Spanish and English flashcard app. Add a word or phrase, and AI turns it into cards with useful meanings, examples, and context. Spaced repetition helps you remember them.
Now available on the App Store.
CLIENT PRODUCT · SPINDLE HEALTH
I built the entire app for Spindle Health. It lets teams tokenize identifying data in Databricks, so records can be linked across organizations without sharing the original identifiers.
One of the first apps in the Databricks app marketplace, highlighted at its launch event.
Two Kotlin libraries that reflect how I like to build software.
05 / THE PERSON IN YOUR CORNER
My career started in aerospace at NASA. Curiosity pulled me into software, and it’s kept me learning ever since.
The engineers on my teams are the experts. I trust them to do their jobs. My responsibility is to give them a clear direction and make sure they have what they need to do good work.
That means paying attention to what’s getting in their way. I’ll run interference when they need to concentrate, work through a decision that’s holding things up, or bring the right people together when a problem needs collaboration.
I also enjoy helping engineers develop beyond the immediate task. That might mean working through a difficult design decision, preparing for a challenging conversation, or helping someone take on more responsibility. Watching people grow into work they weren’t sure they could handle is one of my favorite parts of leading a team.
06 / WORKING TOGETHER
Tell me what you’re trying to do and where you could use some help. We can tackle a specific problem together, or I can work alongside your team for the longer term.
A FOCUSED ENGAGEMENT
You might have a technical decision you’re stuck on, a system that’s becoming difficult to change, or AI-generated code that’s creating more work than it saves.
We’ll agree on what we need to find out. I’ll dig into the code with your engineers, explain what I find, and help you decide what to do next.
AN ONGOING PARTNERSHIP
If you need ongoing technical leadership, I can work with you as a fractional CTO or engineering leader. I’ll help set direction and stay involved in the engineering work, with room to support people and tackle problems as they come up.
We’ll agree on where I can be most useful and how I’ll work with your team.
07 / A LITTLE MORE OF HOW I THINK
For the technically curious.
A closer look at the craft.
Designing software so entire categories of mistakes become harder to make.
Making failure explicit, so engineers can reason about what happens next.
Giving a growing system clear boundaries without rushing into microservices.
08 / LET’S FIND OUT
You don’t need a polished brief.
Tell me a little about your team, your software, or the decision in front of you.
We’ll start with a conversation and see if I can help.
I typically work US East Coast hours to stay aligned with my clients in the US.
Erik DreyerEngineer, architect, and person you’ll work with.