Adalsyn Advisory
Most of this work starts the same way: infrastructure spend growing faster than the business, and no independent way to find out why.
Adalsyn Advisory is the independent technology advisory practice of Jonathan Miller, based in Seattle. Technical due diligence, infrastructure and data architecture, and board advisory.
The recurring client owns a technology outcome but cannot personally assess the technical claims underneath it. The engineering organization says the platform can do what the roadmap needs. The vendor says the migration takes six months. The team recommends a rebuild. All of it may be true, and none of it is independently verifiable from inside the room.
The shapes repeat. Two systems that were supposed to be one system by now, usually after an acquisition. A build-versus-buy decision where the internal team has an obvious stake in the answer. A roadmap that keeps slipping without a clear technical reason.
Services
For investors, private equity firms, and acquirers evaluating a technology asset. Architecture, infrastructure cost structure, and the capability of the engineering organization. The question underneath is usually the gap between what a company says its technology can do and what it can actually do.
Primarily for mid-market, PE-backed companies. Cloud cost diagnostics, data platform architecture, post-acquisition systems integration, and build-versus-buy decisions where the internal recommendation deserves a second read.
Technology advisory to boards and executive teams that need an independent read on technical decisions they cannot evaluate internally. These are standing relationships rather than one-time reports.
This practice does not do staff augmentation or managed services, and it does not resell any platform. Diagnostic engagements are priced and scoped so that the finding does not depend on the recommendation. Where implementation support makes sense afterward, it is a separate decision. Engagements are performed personally. The person you speak with is the person who does the work.
A note on complexity
In mid-market data architecture the honest answer is often that you do not need an expensive modern data stack. Power BI, Azure SQL, dbt-core, and the ERP connectors you already own will usually carry you further than a rebuild, and they will carry you sooner. That answer is worth less in fees than the rebuild. That is part of why it is worth hearing from someone who is not selling one.
Case study
Notes from a recent fixed-scope diagnostic for a connected-hardware company. Details are generalized and no figure here is specific to the client.
The client sold hardware with cloud software attached and had inherited a second product line and a second cloud stack through an acquisition. The working assumption was that the managed IoT platform carrying most of the estate was too expensive and delivery too slow, and that the fix was to finish consolidating onto it and size the team accordingly. The brief was to find out whether that was true.
Every measured number in the deliverable was tied to a primary source: a contract, an invoice, a line in the P&L, a repository, a telemetry export. Interviews said where to look and were never evidence on their own. Per-device usage was pulled programmatically across the fleet and reconciled against billing exports over more than one day, because a single day can mislead. Each agreement the client provided was read in full.
Findings shipped in stages with the evidence workbook, so the sponsor could challenge the numbers before recommendations were built on them. Every figure was labeled measured, modeled, or a range.
Most of the platform charge moved with what devices were configured to send rather than with contract terms, which is what made it addressable without a renegotiation. The platform priced each device by how much data it sent, in bands far apart, so identical devices could land in very different bands depending on configuration. About half the billed fleet had sent no data at all. A material share of billed traffic was internal telemetry that did not need to travel the metered path, a second cause behind a problem that had been attributed to one. Compute was billed at declared limits rather than actual use, and nobody could see actual use because the estate was uninstrumented.
The consolidation that had been assumed as the destination ran into the client’s own customer agreements, which constrained how the regulated product’s data could be hosted. That made the platform question the reverse of the one asked. And the delivery problem was ownership rather than throughput: the software organization lacked dedicated product and architecture roles, so commitments had no single owner.
Six steps worth roughly a third of the platform bill, with no migration and no renegotiation. A firm recommendation against moving the regulated product, referred to counsel. Staying on the platform for now and scoping the alternative properly, with the rebuild estimate left to the people who would deliver it. Two senior hires, in architecture and product, and a decision rule agreed in advance for whether to rebuild.
And a direct answer on the savings target: not reachable on cost efficiency alone. Technical work closes a little under half of it. The remainder is a decision about what the software function is for, and the client now has the evidence to make it.
Background
Jonathan Miller has spent more than fifteen years across hyperscale platforms, startup leadership, and hands-on engineering.
Most recently he was co-founder and CTO of BaseCap Analytics, a data quality platform serving Fortune 500 financial services firms. He built and led the company to approximately thirty people through to an acquisition, and served as technology advisor to its board. He owned cloud economics directly, meaning architecture, vendor decisions, and spend, with the company’s own capital at stake. The platform shipped a customer-facing GenAI capability that translated plain-English data quality rules into an executable rules engine, and a distributed anomaly detection engine running in production inside regulated financial institutions.
Before that he led a technology business unit at Riot Games, an organization of approximately thirty people through three engineering managers, spanning tournament operations and scheduling, real-time game data pipelines, and game integrations including competitive integrity, anti-cheat, and broadcast technology. He re-architected the live game-data pipeline from REST polling to streaming telemetry, which moved delivery success from about 80 percent to 99.9 percent and cut latency from seconds to roughly 250 milliseconds for downstream data partners. That pipeline carried regulated data, including KYC, gambling prevention, and government oversight reporting.
At Apple he worked on privacy-preserving cloud infrastructure and messaging transport at hyperscale. Before that came nine years at Microsoft across platform reliability and developer technologies, including Xbox, Adaptive Cards, .NET, and OneDrive. That work included driving an interoperability standard that internal product groups and external developers had to choose to adopt rather than being told to.
He continues to design and build custom cellular-connected IoT hardware, which puts device-side telemetry design inside the scope of the practice, including sampling intervals, payload structure, and edge aggregation, rather than only the cloud end of a data pipeline.