In June 2024, I took a pay cut to leave AWS and join Apira Technologies to build the technical vision from the ground up.

We just sold.

Up until this job, I spent my career as an individual contributor. I prided myself on doing things the RIGHT way. My primary audience was other engineers who might read my code.

That’s backwards.

We didn’t win by being the smartest or writing the cleanest code. We won by asking the same question at every turn: Are we building something customers will actually pay for?

A few reflections.

Build good enough, not perfect

Businesses fail because they run out of cash. Not because their code wasn’t elegant. Not because they didn’t hit 100% test coverage. Not because their infrastructure diagram wouldn’t look good on a conference slide.

Spaghetti code yeeted onto an EC2 that customers will pay for keeps you alive. A perfectly architected system that no one will pay for is shelf-ware.

Senior engineers love to dismiss AI-written code as “lower quality.” They’re probably right.

It also doesn’t matter.

Speed matters. Shipping what customers actually want matters. AI-written code that solves a customer problem today is better for business than perfectly written code shipped in two weeks.

A business exists to solve customer problems, not to give engineers a stage for intellectual superiority.

Talk to customers. Hear their pain. Ship what they need, fast. Earn credibility. The AI world moves at breakneck speed. Filter everything through two questions: “What would a customer want?” and “How does this solve their problem?”

That’s how you stay ahead.

If you can’t sell, align with people who can

Our main customer is government. Building a solid technical product gets you 15% of the way there. The other 85%? Relationships, contracts, and procurement.

I had zero experience with that. So I aligned with people who did.

Here’s the deal: they need something good to sell. We can’t invest in technology without revenue. Simple.

When engineers think sales doesn’t matter, or when sales promises features that can’t be built, everyone loses. The boat tips. You’re done. Everyone rows in the same direction, or you sink.

Give your builders context, then hire for judgment

Engineers make dozens of tradeoffs every day. When they understand the customer, what’s needed, and why, those tradeoffs become obvious.

Fewer meetings. Fewer GitHub issue novels. Less back and forth.

When I gave my team “here’s what we need and why,” they innovated in ways I never would have thought of. They surprised me. Why? Because they had the context to actually solve problems instead of just following orders.

In the age of AI-enabled IDEs, hiring has to change. I never made anyone whiteboard a binary tree inversion. I don’t care. An LLM can do that in seconds.

Instead, I had them talk me through:

  • How they make decisions
  • How they approach problems
  • Projects they’ve worked on and the tradeoffs they made

Hire for give-a-shit factor. That’s what matters.

Demo the value, not the tech

When demoing software, don’t show the hard part you’re proud of. Show what customers care about.

We once sat through a 90-minute meeting with another tech company in our space. They burned 80 minutes walking through two products:

  • Ten minutes stuck on a login screen. Three attempts. Different environments. Finally got in.
  • Twenty-five minutes at a whiteboard explaining how one product worked. Lots of words. Very little working software.

I took the last 10 minutes to demo two of our products. Straight to the value. Their jaws dropped.

Why? Because I showed the value prop immediately. No excuses. No explanations. Just working software solving real problems. Everyone in the room understood it and started spinning on use cases.

Nobody cares how smart you are. They care what problem your product solves.

This is only the beginning. I’m not slowing down.

Someone out there is working harder, ready to eat my lunch.