This week, we sat down with Alex Nelson, CTO at GUIDEcx, whose career path took a detour most engineers never see coming. Alex shares how his early days as a technology auditor at American Express and PwC shaped a fundamentally different way of thinking about systems: through the lens of risk, controls, and failure modes. From pulling off a live Heroku-to-AWS migration while building an engineering org from scratch, to keeping security from ever becoming a speed bump, his approach is equal parts disciplined and pragmatic. If you're building software at any scale, there's something in here for you.
You started your career as a technology auditor at American Express and PwC, and somehow ended up as a CTO building distributed SaaS systems. Walk us through that plot twist — what connected those two worlds for you?
I had actually been doing web development since high school, and that’s what originally drew me to the Information Systems program. It felt like a good mix of development and business.
At the time, the program really pushed the “Big 4” path, and I followed that into technology auditing at American Express and PwC. But even while I was doing that work, I kept finding ways to use my development skills to make the job easier by building small tools and automating parts of the process.
Over time it became pretty clear that I enjoyed building systems a lot more than auditing them, so I made the shift into more technical roles.
That auditing background ended up being really valuable. It trained me to think about systems in terms of risk, controls, and failure modes, which is something a lot of engineers don’t get early in their careers.
That perspective has carried through into what I do today. For example, at GUIDEcx I led our SOC 2 efforts and ongoing compliance readiness, and having that foundation made it much easier to translate those requirements into how we actually build software instead of treating security and compliance as an afterthought.
You were GUIDEcx's very first in-house engineer, and within two years you were the CTO. What was it actually like carrying an entire company's technical future on your shoulders from day one, with no engineering team to lean on?
It was equal parts exciting and a little intimidating, but I wouldn’t say I was going at it alone.
When I joined GUIDEcx, I was the first in-house engineer, but we had a strong partnership with a company called Ravn. They had helped the founder get the initial product to market before the company started hiring internally. My first responsibility was to soak up as much domain knowledge as I could from that team and then start putting plans in place for how we would scale the product from there.
Ravn remained great partners through those early years. We effectively embedded them into our team, which gave us continuity while we started building our in-house engineering organization.
We were also able to hire a few key engineers pretty quickly, which made a big difference. From there, the challenge became less about doing everything myself and more about making the right decisions as a team.
I’ve always really enjoyed the craft of software development, so I loved those early days. There’s something fun about inheriting a codebase, understanding how it works, and then making thoughtful, iterative improvements. At the same time, we were adding new functionality and making sure the platform could keep up with the pace of growth.
You made the call to migrate GUIDEcx off Heroku and onto AWS while simultaneously building an in-house engineering org from scratch — two of the riskiest moves a growing SaaS company can make. What was the moment you realized you could pull both off at the same time?
At the time, it was becoming clear that we were starting to hit the limits of what Heroku was designed to handle for our use case, especially around scale, observability, and cost control.
We also had the benefit of a relatively simple tech stack, and I had a lot of experience with containerized systems and AWS. Given the growth we were expecting, it became a pretty straightforward decision to move early while things were still simple and before we reached a truly mission-critical stage with customers.
That said, I wouldn’t recommend this approach for every team. It really depends on the product, the business priorities, and what the team can realistically support.
For example, we were intentional about not over-engineering the solution. Moving to something like Kubernetes at that stage would have added a lot of operational complexity that we didn’t need. A more managed approach like ECS gave us the flexibility we wanted without the overhead.
Similarly, if our growth projections were different or if we were targeting a more SMB-focused market, it might have made more sense to absorb the higher cost of Heroku and optimize for simplicity.
So I still believe it was the right decision for us at the time, but in a different context, I could absolutely see us making a different call.
From an execution standpoint, we broke the migration into smaller, incremental steps and built in AWS alongside our existing Heroku environment. That allowed us to move gradually, learn as we went, and keep risk under control.
You've led teams through SOC 2, GDPR, and enterprise-grade compliance at a startup scale — a space where most fast-moving teams cut corners. How do you build a culture where security and reliability are treated as competitive advantages rather than speed bumps?
I don’t think security slows teams down, as long as those principles are well understood and implemented early.
If you prioritize automated quality gates and controls from the beginning, your team is set up for continuous delivery with those controls already baked in. It becomes part of how you build and ship software every day. It’s much harder to retrofit that later if you didn’t design for it upfront.
And if you design those controls correctly, proving compliance becomes much easier. You’re not scrambling to gather evidence. You’re just demonstrating what your system is already doing.
My background in technology auditing shaped a lot of this thinking. I’ve seen what happens when security is an afterthought, and it’s usually painful to fix.
At this point, strong data security is table stakes in SaaS. Standards like SOC 2 or ISO 27001 aren’t just checkboxes. They build customer trust, speed up procurement, and can even be a competitive advantage. We leaned into that early at GUIDEcx and saw those benefits firsthand.
So for us, security isn’t a separate step. It’s part of how we design, build, and operate the platform from day one.
Your background spans auditing, solution architecture at Domo, payments at PayClip, genealogy tech at Ancestry, and now client onboarding at GUIDEcx — industries that couldn't be more different. How has that unusual breadth shaped the way you design systems and make architectural decisions today?
Working across very different industries has been one of the most valuable parts of my career.
On the surface, payments, genealogy platforms, analytics systems, and onboarding software all look very different. But underneath, a lot of the same core problems show up over and over again. Things like data integrity, scalability, integrations, and reliability.
One concept I’ve come to rely on is designing systems around volatility.
A common trap engineers fall into is building systems that mirror the current product requirements too closely. It feels intuitive, but it makes the system much harder to evolve as those requirements change.
Across these different industries, what I’ve learned is to focus on identifying where change is most likely to happen and designing around those points of volatility.
When you look at systems through that lens, the work becomes much more consistent. Regardless of the business domain, you’re solving similar problems, isolating change, managing dependencies, and creating flexibility where it matters most.
That perspective has helped me make more durable architectural decisions that hold up as products and businesses evolve.
As a CTO at a growing SaaS company, how are you actively weaving AI into GUIDEcx's engineering workflow and product — and what's the hardest part about doing that responsibly without letting the hype drive the roadmap?
The biggest impact we’re seeing from AI right now is on the engineering workflow itself.
We’re using it to help engineers move faster. Things like navigating large codebases, generating scaffolding, improving test coverage, and speeding up iteration. Those gains compound pretty quickly across a team.
On the product side, we’re being more deliberate. The goal isn’t to add AI for the sake of it, but to apply it where it actually reduces friction for our customers. Things like automating repetitive tasks, surfacing insights, and helping teams move projects forward more efficiently.
The hardest part right now is separating real value from hype.
AI is moving incredibly fast, and it’s easy to get pulled toward whatever is new or trending. But product decisions still need to be grounded in customer outcomes. Just because something is possible doesn’t mean it’s useful.
So we try to stay disciplined. We focus on areas where AI can meaningfully improve the experience or eliminate real work for our users, and we avoid forcing it into places where it doesn’t belong.
It’s less about chasing the technology and more about applying it in ways that actually make the product better.
We hope you enjoyed this edition of Coffee with Calyptus. Stay curious, stay inspired, and keep building what matters. Explore more editions and insightful articles at .
