The Engineering
Behind the Work
Most of what makes a system dependable is invisible from the outside. This page is what does not fit on a services page: how your work is handled, what Saul Tapia has built across fifteen years, and what that means we can build for you. You will not find a client name anywhere on it, and that is deliberate.
Your Work Stays Yours
Two questions matter before any code does: what we do with what we learn about your business, and who owns what gets built. Both answers are in our Terms of Service, not only on this page.
Your work stays private
We share a client name, logo, screenshot or case study only with that client's written permission. That is a standing policy, not an empty shelf we plan to fill later, which is why you will not find one on this site.
Nothing of yours in our marketing
Your data, your screens and the way your business runs stay out of our website and our examples. Every illustration on this site is arithmetic on assumptions stated on the page.
You own what we build for you
After full payment, the client-specific work, the accounts and the documentation are yours. Tools and reusable components we bring stay ours, and you keep the right to use them as part of the finished work, as our Terms of Service describe.
The least access that will do the job
Service credentials live in your accounts with the narrowest permissions the work allows. We work inside the access you grant, and we expect you to revoke anything we no longer need at the end of the engagement.
Some information should never leave the environment it lives in, and some businesses are not permitted to send it to a third party at all. For that work the model itself runs inside your own cloud account or on hardware you control, so the request never reaches a provider you do not control. We can say that plainly because we have operated it: sizing the hardware, choosing a model genuinely good enough for the task, and measuring it against your real work rather than a public benchmark.
Fifteen Years of Systems That Had to Stay Up
Everything below was designed, built and operated by Saul Tapia, our co-founder. It is described without naming the organizations it was built for, and none of it is offered as a project of this firm. It is simply why we can tell you plainly what we can and cannot do.
Private model inference in production
Language models on privately controlled infrastructure, in continuous production rather than a trial, serving agent workflows around the clock without sending the underlying records anywhere else.
Agent systems with a person in the loop
Agents that gather information from websites, files and APIs, check it against fixed rules, and route anything uncertain to a person instead of acting on a guess.
Workflows that survive an outage
Long-running workflows that resume after a restart, replay step by step to show exactly what happened and when, and keep model recommendations separate from the code allowed to change a database.
Data pipelines that produce predictions
Live and historical data combined into operational predictions, refreshed on a schedule that understands its dependencies, so a late input does not quietly produce a confident wrong answer.
APIs and the infrastructure under them
REST APIs rebuilt for throughput and response time, on cloud infrastructure sized for the load it actually carries rather than for a demonstration.
Market data analyzed in real time
Agents reading and analyzing market data as it arrives, on a privately hosted model, where no strategy is trusted until it has been tested against history and held to firm risk limits.
Built and operated by our founder. Not a client project of this firm.
Three Things Not on a Skills List
Design, not just development
Saul draws. Interfaces, diagrams and artwork do not go out to a second vendor, and a build does not have to look like a developer designed it.
He has run a product, not only built one
His first company was a product with real users that he designed, built, launched and eventually chose to close. That is a different instinct from contract work: what to build first, what to leave out, and when something is finished.
English and Spanish, first-hand
Both owners work in either language. Nothing routes through a translator, and nothing is lost between what you meant and what was built.
The Work That Has No Page of Its Own
Our nine service pages are what we are asked for most often, not the limit of what we can do. These six come from the same fifteen years, none of them has a service page, and they run from a small fix to a system your business depends on. If what you need resembles one, it is worth asking.
Long-running work that survives failure
Processes that take hours or days: they resume where they stopped after an outage, never silently repeat a step, and can be replayed afterwards to show exactly what happened.
Rule-driven routing, scheduling and assignment
Engines that choose the best option against your rules and constraints the same way every time, instead of leaving it to whoever happens to be handling the case that day.
Predictions built from your own history
Models that combine live and historical records to estimate what will happen and when, with accuracy measured against what actually happened rather than asserted.
Making a system you already have faster
Profiling and rebuilding slow APIs, queries and pages for response time and throughput, on systems already carrying real traffic, without a rewrite.
Proving it works before you rely on it
Testing a model, a rule set or a strategy against history, holding it to thresholds agreed in advance, and reporting honestly when it does not clear them.
Working alongside your own developers
Architecture review, performance work and a second opinion on a decision that is hard to reverse. Sometimes the right engagement strengthens the team you have rather than replacing it.
Where AI Projects Go Wrong
A language model is probabilistic. The systems a business runs on are not allowed to be. Nearly every AI project that disappoints does so at that seam, which is where most of the engineering effort belongs.
Fixed checks around uncertain output
The model proposes, and deterministic rules decide what is acceptable. Anything falling outside those rules never reaches your records in the first place.
Human approval on anything consequential
Actions that are hard to undo or expensive to get wrong are prepared for a person to approve rather than taken alone. Which actions those are is your decision, not our assumption.
Safe to run twice
Every step is built so that repeating it cannot create the same record twice. That is the property that makes automatic retries and recovery safe instead of dangerous.
A record of every step
What was read, what was proposed, what a person approved and what actually changed, kept so a question asked months later has an answer rather than a theory.
AI Where It Earns Its Keep
A bigger model, a longer context window, more agents and more tokens are not automatically a better solution. They are a bigger bill and more to maintain. We start with deterministic code, the software you already own, queries, APIs and plain automation, and use AI where those cannot reliably do the job: small models first, frontier reasoning only for the work that genuinely needs it.
A feature you already own
Software you already pay for often does it. Someone just has to turn it on.
A setting or a business rule
A configuration change, or a plain if-this-then-that rule.
A query, script or API call
A few dozen lines that move or check data on a schedule.
Conventional automation
The same steps, the same way, every time, with error handling.
A small, specialized AI model
Reads, sorts or extracts where rules cannot, at a fraction of the cost.
A frontier AI model
The largest models, for reasoning that genuinely needs them.
AI agents working together
Several AI steps acting with some autonomy, only where the job demands it.
We climb only when the rung below cannot reliably do the job. A way of thinking, not a checklist: many jobs finish on the lower rungs, and some start higher because the problem demands it.
What We Actually Work In
Not a list of everything we have heard of. These are the tools we build in often enough to be accountable for.
Languages and frameworks
JavaScript and TypeScript, Node.js, Express, React, Vite, Python, C#, PHP, HTML and CSS.
Data
PostgreSQL, SQL Server and T-SQL, MySQL, DynamoDB, REST API design, ETL and data pipelines, reporting and operational analytics.
Cloud and delivery
AWS, including Lambda, S3, EC2, ECS and Fargate, Aurora, SQS, CloudFront, Route 53, IAM and KMS, with Docker, Git and automated build and deploy pipelines.
AI and automation
Local and hosted model inference, agent and tool orchestration including LangGraph, durable workflow engines such as Temporal, retrieval over your own records, human-in-the-loop review and deterministic validation.
What We Will Not Claim
The quickest way to judge a technology firm is by what it refuses to promise.
- We do not publish an accuracy percentage for model output. Accuracy depends on your documents, so we measure it on your documents and show you the result before you rely on it.
- We do not present illustrations as client results. Every figure on this site that resembles a case study is arithmetic on assumptions stated on the page.
- We do not guarantee outcomes we do not control, including the behavior of a third-party model, a provider raising its prices, or a provider outage.
- We do not claim credentials we do not hold. We are not a law firm, an accounting firm, or a compliance or regulatory advisor, and we will say so rather than improvise.
- We do not take work we are not right for. If your project needs something outside what we do well, we would rather tell you at the start than learn it on your budget.
Reasonable Questions About All This
- Why are there no client names or case studies anywhere on this site?
- Because a client’s systems are theirs, not our marketing material. We will publish a case study when a client approves one in writing, and not before. Until then this page is the honest version of the same evidence: what has been built, how it was built, and what we refuse to promise.
- Is the experience on this page work done by this firm?
- No, and the difference matters enough to state plainly. The systems described above were designed and operated by our founder over more than fifteen years, and they are not projects of T&C Group Holdings, LLC. They are the basis for what we are willing to take on, which is a different claim from a portfolio.
- When you say private AI, do you mean the model itself or just a private API key?
- The model itself, running on infrastructure you control, inside your own cloud account or on your own hardware, with the request never leaving it. A private API key is still a third party receiving your data under terms they write and can change.
Tell Us What It Has to Do. We Will Tell You If We Can Build It.
Describe the process, the system or the idea in your own words. You get a written scope and a real number before you spend anything, and an honest answer if we are not the right firm for it.