Why we started RegainFlow: building the firm we wanted to work for
We started RegainFlow in January 2025 so that experienced engineers have a say in what they build, clients know who is building it, and good work holds up long after the engagement ends.
TL;DR
- The engineers who scope the work build it, working alongside the people who will use it.
- A system has to serve leadership and the people doing the work, or it stalls.
- Data maturity, interoperability and permissions come first; AI without them is a band-aid.
- Regulated and secure environments can have modern AI when the constraints are designed in from the first week.
- We design every engagement so the client can run the system without us.
On this page (8)

Leo and I have both been the engineer an organization relies on a little too heavily. We cared about the work, took ownership of difficult problems, and put in the hours to get things done. But we often had little influence over which problems were worth solving or how the work was carried out.
We also saw the same frustrations from the other side. Companies spent heavily on consultants, staffing firms and software projects, only to end up with systems their teams struggled to use or maintain. There were plenty of capable engineers involved. Somewhere between the people making decisions, the people building the technology and the people expected to use it, things got lost.
In January 2025, in Orlando, we started RegainFlow to approach that work differently.
Engineers who work alongside your team
We've always believed the best engineering happens close to the problem.
At RegainFlow, the engineers who help scope a project are the same people responsible for building it. We work directly with the people who will use the system, learn how their work gets done, and stay involved through deployment. Some firms call this forward-deployed engineering. For us it is simply how the work should be done.
A requirement that makes sense in a meeting can fall apart when someone tries to use it during a busy workday. A seemingly minor inconvenience might turn out to cost an entire department hours each week. We want our engineers to have the freedom and responsibility to notice those things, question assumptions, and make better decisions with the client.
It also means being accountable for what happens after the software is delivered. If a system requires constant intervention from the people who built it, we haven't finished the job.
Understanding the whole organization
One thing we've learned is that leadership and the people doing the work often see different parts of the same problem.
Leadership might want faster decisions, lower operating costs, or better visibility into performance. Someone closer to the work might tell you about a procedure nobody can find, information being copied between systems, or the one experienced employee everyone depends on for answers.
A project can satisfy every requirement leadership approved and still make someone's daily work harder. It can also solve an employee's immediate frustration without making a meaningful difference to the business.
We spend time with both groups because good solutions have to account for both. The people doing the work help us understand what needs to change. Leadership helps establish why it matters and how we'll know whether the investment was worthwhile. We've explored this further in our report, Closing the Ambition Circuit.
Getting the foundations right
AI has created opportunities to solve problems that were previously too expensive or impractical to address. We're excited about that, and much of our work involves making those capabilities useful inside real organizations.
But we've also seen how quickly enthusiasm runs into existing problems with data, software and processes. An organization might have years of valuable engineering records that nobody can search effectively. Different departments may use systems that don't exchange information. Documents may be duplicated across shared drives, with no clear way to identify the current version.
Adding an AI model doesn't resolve those problems on its own. Put on top of them, it is a band-aid.
Sometimes the right starting point is better document retrieval. Other times it's connecting two systems, improving a workflow, or establishing reliable data and access controls. We want to understand what's actually getting in the way before deciding what technology belongs in the solution.
When AI is appropriate, we put the engineering around it: reliable data, permissions, testing, monitoring, and a way to measure whether it's helping. That foundation tends to outlast any particular generation of AI models.
Working where reliability matters
Our backgrounds include law enforcement, aerospace, defense and large enterprise systems. We've worked in environments where security requirements, audits, restricted infrastructure and lengthy approval processes are part of everyday engineering.
Organizations like these are often told that modern software and AI are for someone else, or that they will have to wait until the rules catch up. We disagree. They are often where reliable systems count most, and the constraints can be met when they are part of the design from the first week rather than retrofitted later.
For some clients, that means keeping data and models inside their own infrastructure. For others, it means making sure a system respects existing permissions, records its activity, or can withstand the scrutiny of a security review.
How we work: the FLOW method
We've organized our approach into four steps that keep us focused on the problem and the result.
Find the value leak
We start by understanding where the organization is losing time, money, quality or momentum. That gives us a problem worth solving and a basis for measuring improvement.
Listen across the chain
We speak with leadership and the people closest to the work. We look at the existing systems, the informal workarounds, and the places where expectations differ from reality.
Operationalize the context
We put the necessary data, integrations, permissions and processes in place, then build the solution around how the organization actually operates.
Watch the outcome
We measure what changed, find out what's working, and address what isn't. The feedback informs the next round of improvements.
In practice, we begin with an assessment, identify a manageable first production workflow, and build something that can be used and evaluated in daily operations. From there, we can continue supporting it or transfer ownership to the client's team. Our services page explains how those engagements are structured.
Why the name RegainFlow?
Regain speaks to getting back the time, capability and momentum organizations lose through unnecessary work, slow decisions and inaccessible knowledge.
Flow describes what we want to help create: an environment where people have the information and tools they need to do their jobs without constantly working around the systems meant to support them.
The standards we hold ourselves to
We wrote a manifesto early on to set some boundaries for how we operate. A few have become particularly important to us.
- A pilot is not a result. We want our work to make it into production, where people can use it and see whether it helps.
- The people who scope the work build it. We believe in direct responsibility and keeping unnecessary layers out of the relationship.
- We measure what we promise. We agree on what success looks like and report against it, including when something falls short.
- Nobody gets used. We want relationships where our engineers can take pride in their work and our clients receive something worth what they paid.
- You should be able to leave. Documentation, training and knowledge transfer belong in the engagement. Clients should be able to operate what we've built without depending on us indefinitely.
The people behind RegainFlow
RegainFlow was founded by two engineers with different backgrounds and a shared view of how engineering services should work.
Leo, our CEO, brings experience as a staff full-stack engineer and AI/ML technical lead, along with his previous service as a U.S. Army captain in engineering, signal and cyber roles.
William, our CTO, focuses on the engineering needed to make software and AI systems dependable in production, including data infrastructure, deployment, observability and operating costs.
We started this company because we wanted more ownership over the work we did and a better relationship between the people building technology and the people relying on it.
If your team is dealing with scattered knowledge, disconnected systems, or a technology project that's struggling to reach production, we'd be glad to hear about it. We usually start with a free assessment to understand the problem and whether we're the right people to help.
