A CTO who still reads the code.

Netsmart has worked with me since 2012, across two of my companies. That is the part I would point at first: this is not a project, it is a fourteen-year relationship, and the hard work only gets handed to people who have already earned it.

Most recently, leaving a private data center for AWS: roughly 1,800 tables and 8TB of data off Oracle and onto Aurora PostgreSQL, driven by Oracle licensing costs and the smallest downtime window we could manage. It became considerably broader than that in practice. The Java application had to be containerized onto ECS, Oracle-specific database logic had to be rewritten, reporting had to move off SQL Server onto Redshift, and networking and performance had to be reconsidered for a cloud environment entirely.

My focus early was finding the risk in the data layer and shaping a phased approach around it. Oracle-specific behavior sat deep inside stored procedures. Date and time handling had to be evaluated case by case, because no global rule existed. Primary keys that were perfectly fine in Oracle had to be rethought as BIGINT. Performance assumptions did not survive the move. None of that appears in an architecture diagram. It appears when you start moving things.

So we broke it into four phases to bound the risk: application to AWS on containers with Oracle still in place, Oracle to RDS to cut the data center dependency, Oracle to PostgreSQL, then reporting to Redshift.

The first full cutover did not go well. We had load tested and validated the key workflows, but real users surfaced performance problems tied to years of tuning and client-specific optimization that were never in our test scenarios. We rolled back — which was possible only because the phasing had been built to allow it. The whole thing was harder and more expensive than anyone planned for. The platform is now fully on AWS and PostgreSQL, positioned to actually use cloud-native architecture rather than reproduce what was there before.

ABOUT was evaluating a company it intended to acquire and needed more than a surface read on the target's technology and product organization. So we built a multi-factored model that drills into a digital product company across three dimensions.

• Strategy — Where is the product headed, and why? What does the company actually intend it to become?
• Performance — How is it performing today? How do customers find it, how effectively does the organization convert opportunities, and what does retention look like?
• Capabilities — How well does the organization execute the strategy? What is the team like, how do they build, and is the technology appropriate to the stage they are actually in?

That last clause is the part that makes the model work. Products move through common developmental stages, and one still hunting its first customer cannot be judged against a mature one without producing conclusions that are both unfair and wrong — and that obscure what is genuinely good about the business. Every finding is weighed against the stage the product is actually in. For a target with a portfolio that means several answers rather than one, and the gap between them is usually where the interesting findings are.

We gathered what we could through conversations, artifacts, and observation, then tracked each answer, judged whether it was developmentally appropriate, and classified the risk attached to it. The deal team came away with a defensible, comparable picture of what they would be buying — and, just as usefully, a costed view of what it would take to fix.

The founders are not technical, but they know their business cold: they run a successful wealth management firm, and years of that had shown them exactly where the tooling falls short. The product idea was to sit on top of the many back-office applications a wealth management firm depends on to serve its clients. That is genuine founder insight, and it is why the company was worth advising in the first place.

The build had been contracted to an outsourced firm with a local account rep and an engineering team overseas. The first call I joined had ten people on it. The only user was the founders' own firm — real validation, but not the same test as a first customer with no stake in the company.

A month in, the money was going into hand-coding an identity model in Azure and standing up infrastructure sized to one firm's requirements. Meanwhile the thing the product actually needed — a way to integrate the assorted back-office systems a second customer would arrive with — did not exist. Much of the build was either mature-company work or so specific to one integration that landing customer two would cost about what customer one had. And ten people were burning cash against zero revenue.

So I pushed them to stop and rebuild for the stage the product was actually at — what gets you to the next phase of the lifecycle, not the one after that. They did, and it cost a fraction of what continuing would have.

The product has not gone to market. It is in use inside their own firm, which is real value, but the outside launch has not happened yet. I would rather say that than round it up: outside advice can redirect what a company spends and stop a bad trajectory early, and here it did. What it cannot do is decide when, or whether, a company goes to market — that call belongs to the founders, and weighing it against a firm that already works is a reasonable thing to take time over. The spend was significant. On the original trajectory it would have been far larger.

Two custom applications needed modernizing: WebLEM, the labor-estimating platform, and NCPWB, which serves their certified pipe-welding bureau. Both had been built as independent silos. Meanwhile a growing list of third-party software vendors were integrating MCAA's labor data into their own products, with no coherent way to understand who was using what.

Part of my role is simply being the technology function they do not have: finding development partners who are genuinely good, then managing those relationships closely enough that the work actually lands. They also needed a real identity strategy — both to give members one coherent experience across applications, and to see how members and third parties were using their data. Rather than solve that twice, I made the call to stand up one shared platform environment that both the labor and welding applications sit on: a single identity model built on AWS Cognito, one set of common services, and Salesforce membership as the source of truth. Identity is not worth hand-rolling — the judgment was in the membership model and the integrations, not in reimplementing authentication that Cognito already does better than we would.

The WebLEM overhaul ran with an outside development agency that I oversaw, with me as architect and a hands-on contributor alongside them. The legacy application had business rules hardcoded throughout the codebase, so the real first task was modeling the domain properly — the part of this work I care most about getting right. Once the model was sound, the harder problem was moving decades of legacy data onto it: roughly 165,000 labor units, each one a number some contractor will eventually put on a bid. I leaned heavily on AI to build a comprehensive migration and validation system that checks the new engine against the legacy output across all of them, rather than trusting the migration on faith. In an estimating product, a difference in the fourth decimal place is a real dollar figure on a real job.

The NCPWB rewrite began a few months ago with a team I would put against anyone's, and it is already integrated with the shared platform services. Significant UA integrations are ahead, and they will create real value on all sides.