I didn't set out to start a consulting firm.

My background is in QA, then software engineering, then founding engineer roles, then CTO at an early-stage startup — where I wore every possible tech-related hat there was to wear. Architecture, hiring, process, product decisions, infrastructure, aligning developers with business priorities. All of it, often simultaneously.

That path gave me something I don't take for granted: a full view of how technical decisions actually play out inside a business. Not just the code — but the people writing it, the founders depending on it, the timelines attached to it, and what happens when any of those pieces fall out of alignment.

The pro-bono period

For a little over half a year before starting Helix, I was doing pro-bono consulting. Not as a strategy — it started organically, helping founders and teams I'd connected with work through technical problems.

What I found, consistently, was that the gap wasn't talent. Most teams had capable people. The gap was in how technical work was being structured, communicated, and delivered. Requirements that weren't clear enough before development started. Developers building the right things in the wrong order. Founders without enough visibility to course-correct before small problems became expensive ones.

That half-year made it clear there was a real market for what I was already doing. Helix followed from that.

The code ownership thing

This one is personal.

I've been on the client side of this. I worked at a company that brought in an external developer to build a core part of the product. When the relationship ended, maintaining and building on that code became a serious problem. The business didn't fully own what it had paid to build.

That experience is directly why code ownership is a principle at Helix — not a policy. Everything we build goes into repos under your account. You can take the work, extend it, hand it to another team, or move on entirely. The software is yours, without conditions, from day one.

Why there are no account managers

I'm not a salesperson by trade. I'm a builder, an engineer, a planner, and someone who gets things shipped.

The no-account-manager structure isn't a cost decision — it's a reflection of what actually helps clients. When you work with Helix, you work directly with the people building your product. No layer translating between what you need and what gets built. Fewer hand-offs, less loss in translation, and a team that's accountable because there's nowhere to hide behind process.

What the "actually" means

The copy on this site says things like "web platforms that actually ship" and "a development partner you can actually rely on." That word is doing real work.

I've been in the room when things didn't ship. I've watched promising products stall because the technical foundation wasn't right, the process wasn't aligned, or the team didn't have the right guidance at the right stage. I know what good execution looks like — and what it costs when it's missing.

The "actually" comes from that experience. It's not a marketing line. It's the specific thing we're here to be different about.

What I want for the companies we work with

I want to see your idea succeed. I'm adaptable on tools and process — I won't force a methodology on you, but I'll guide you toward what makes sense for your current stage. I know how to hire and motivate software developers in SaaS. I know how to align teams on requirements and keep them moving.

What I'm not going to do is sell you a dream or pad the work. The goal is to deliver results — and to actually care whether the thing we're building together goes somewhere.

That's what Helix is built around. It took a while to get here, but it's where I was always headed.