About iTech88

INGLEWOOD TECHNICAL SOLUTIONS 88, LLC, a California tech company, was founded in 2021 in Inglewood, California by J. Baker. It trades as iTech88.

The business is deliberately hands-on. We work directly with a small number of clients on the systems their businesses actually run on — building data pipelines between the platforms they use, automating the reports they’d otherwise assemble by hand, analyzing the data those systems collect, and setting up the hardware and software underneath it all. The company also builds its own software; see Software.

The founder, in his own words:

I started as a solutions analyst on an enterprise SaaS platform for insurance and benefits administration, working out of Chicago and learning the trade to accurately gather business and data requirements, writing user stories and use cases, and learning early what it costs when a requirement reaches a developer under-specified. In 2017 I moved to Los Angeles, because the work I wanted was here. California technology companies were building the data platforms I wanted to be inside of rather than adjacent to, and that move set the direction of everything after it.

Four years at an enterprise SaaS company in Santa Monica taught me data at scale. I designed and documented the ETL and reporting layer, wrote the SQL that proved it against SQL Server and Postgres, and took reporting accuracy up fifteen percent. I led the team that cut fifteen thousand scheduled data feeds over from Windows Task Scheduler to JAMS across four datacenters — a migration where one mis-mapped schedule is a silent, customer-visible data outage. Alongside it: backend data integration, UAT and end-to-end validation of analytics enhancements, and the data-flow diagrams the rest of the organization navigated by.

In 2021 I moved into consulting as a technical integrations consultant, specifying more than fifty ETL and REST API integrations on Dell Boomi that moved data between Salesforce, AWS, and internal platforms for global POS and reporting. Functional specifications, field-level data mappings, ingestion and validation behavior, and the delivery cycles that proved each pipeline landed what it claimed. That was the year the work stopped feeling like a job description and started feeling like a practice — so I registered the LLC.

From 2022 to 2024 I was a senior business systems analyst and systems administrator at Coinbase, and learned from the smartest minds in Silicon Valley. I led application rationalization and sunsetting across the enterprise stack with goals of consolidating platforms, tightening data governance, and saving millions of dollars a year out of the run rate while tracing requirements, use cases and success metrics for enterprise analytics and knowledge platforms, including an enterprise AI search rollout, plus the data migrations and reconciliations underneath. I sat close enough to engineering, long enough, to stop believing that analysis and engineering are separate jobs. The engineers were not translating my documents into systems; we were doing one continuous piece of work, and the places it broke were always the places where intent had been written down loosely. I came out of it with an engineering mindset bolted onto an analyst’s instincts, and no interest in choosing between them.

The years since have been the same discipline in different industries. In education operations I mapped eligibility and subsidy data flows, read legacy stored procedures line by line to recover the business logic buried in them for a migration to a modern stack, and wrote SQL against backend databases to prove feature behavior before sprint acceptance — analysis wired straight into QA. In manufacturing and distribution I worked as a NetSuite developer and data analyst, querying SuiteQL against inventory and purchasing data, building the user-facing analytics delivered through Suitelets, and keeping the backend integrations honest. In med tech I studied large data analytics platforms attempting to integrate with legacy systems carrying decades of technical debt — SAP, Salesforce and BW/HANA — defining ingestion patterns, transformation expectations and semantic models for a Microsoft Fabric analytics platform, and establishing the system-of-record, ownership and lineage definitions the rest of the program depends on.

Sixteen years of staying industry agnostic taught me that every industry needs people who can both communicate software and deliver it — and that every one of them fields the same failure: the requirement nobody could trace to an observable behavior. That is where the conviction below comes from.

I build with agentic engineering: AI systems do a large share of the implementation, under a process a human designs and controls. The interesting problem is not the code a model writes. It is everything around it — whether the intent was stated precisely enough to build against, whether the result can be proven, and whether a mistake fails loudly instead of passing quietly.

That is an analyst’s problem, which is why the two halves of my career turned out to be one. The method I hold to is data-driven and behavior-driven development: every behavior is specified in plain language before it is built, and verified against real data after. A requirement that cannot be traced to an observable behavior is not a requirement; it is a hope. Traceability from stated intent, to written acceptance criteria, to a test that runs, to real data, is the only thing I have found that reliably produces software that is correct, maintainable, and still standing a year later.

In practice that means a written standard operating procedure, and the SOP is as much the product as the code is. Work moves in one direction: a story with acceptance criteria, then the scenarios that describe in plain language what working looks like, then the tests, then the build. Nothing gets written until what it has to do has been written down first, and the specification and the code stay tied to each other the whole way through.

What makes it hold is that the process proves itself. “Done” is not an opinion: it is one command that runs the whole suite and either comes back clean or does not, and the standing rule is no done without command output. The checks fire automatically on every change rather than relying on anyone to remember them, and whoever built something is never the one who signs it off. When a problem does slip past, the fix is a new check, not a lesson — so the process gets harder to break every time it is tested. That is what lets AI carry a large share of the work while I stay certain the software is right.

I think this is where software delivery is going generally. As more implementation is delegated to machines, the scarce skill stops being the writing of code and becomes the design of the process around it: the standard operating procedures, the decision records, the gates. That is the discipline iTech88 is built on, and it is applied the same way to a client’s reporting pipeline as to the company’s own software.

The company was founded in Inglewood and serves businesses across Southern California and beyond. Its address of record is in Sacramento, CA.

INGLEWOOD TECHNICAL SOLUTIONS 88, LLC is owned and operated by its founder, J. Baker. His professional background: linkedin.com/in/jcbaker23.