The pitch, and what it does not tell you
You have seen the pitch. A slick site with scroll-triggered animations. GPT-4o mentioned on the homepage. A thirty-minute audit, a strategy plan, a deployment in weeks, an ROI that compounds. A countdown feeling to the whole thing — your competitors are already doing this, why aren't you? A small number of client slots available this month. An agent log on the landing page showing tasks completing themselves.
It is a very particular kind of sales motion, and there are more agencies running it every quarter. The language is consistent enough that you could A/B test the homepages and struggle to tell them apart.
What the pitch does not tell you is what you are inheriting.
Because whatever the engagement delivers — an AI agent, a Zapier pipeline, a React site, a chatbot wrapped around a workflow — you will own it six months after the vendor's last invoice clears. Whether you can actually operate what you have inherited is a different question, and it is the question this post is about.
There are three failure modes that show up in this category of work. They are not rare. They are structural consequences of a business model that optimises for the sale.
Failure mode one: security as an afterthought
The promise of shipping in weeks is not compatible with doing security properly. This is not a moral judgement — it is arithmetic. The work that makes a system safe to deploy is slow, uncomfortable, and invisible in the demo.
It is threat modelling before the first line of code. It is data classification, then data flow mapping, then access control design. It is secrets management that does not live in a dotenv file in a git history somewhere. It is row-level security policies tested against the roles that actually exist in the system, not the roles the architect meant to configure. It is rate limiting, input validation, output sanitisation, dependency auditing, and a disclosure process for when somebody inevitably finds a bug. It is a plan for what happens when the API key leaks — not if, when.
None of that fits into a three-stage process that goes audit, plan, deploy.
And the cost of skipping it compounds in direct proportion to what the system handles. A marketing automation that misfires is embarrassing. A customer-facing agent that leaks data is a notifiable incident. A platform that handles identity documents, minors, health information, or financial records — built by a small team under a "weeks, not months" commitment — is a category of exposure that does not belong on a standard agency retainer. The regulatory frameworks assume you did the work. Australian privacy law, the Online Safety Act, the obligations around handling identity verification and minors' data — none of these pause because the build was fast.
There is a simple test. Ask the vendor who last pen-tested the system, when, and whether you can see the report. Ask whether a privacy impact assessment was conducted before deployment. Ask what the incident response plan is, and who holds the on-call pager. Most of the time, the answer is a polite version of we'll get to that.
Failure mode two: AI as the default answer
The second failure mode is subtler, because it looks like progress.
The current vogue is to reach for a large language model as the first response to any problem. An agent to handle enquiries. A RAG pipeline over the PDFs. A chatbot in front of the workflow. A generator to produce the content. The stack page of every new agency lists the same handful of foundation-model providers, and the pitch is always that the AI makes the system smarter, faster, more autonomous.
Sometimes this is the right answer. Often it is not.
The question that gets skipped is whether the problem being solved tolerates the failure mode of a language model. An LLM recommending a restaurant can hallucinate with very little consequence. An LLM recommending a material or specification for a structural application can hallucinate with real consequence — a failed part, a wasted job, or worse, a component that fails under load. The same model architecture, the same retrieval pipeline, the same reference corpus — and one deployment is fine while the other is a product-liability question nobody asked. The sales collateral does not distinguish between these cases. The engineering should.
There is also a layer of quiet marketing language that is worth decoding. Systems advertised as "trained on your data" are usually retrieval systems that search your data at query time — which is a different thing, with different failure modes, different costs, and different governance implications. Agents described as "autonomous" usually require significant human-in-the-loop oversight to stay within the bounds of reasonable behaviour, and when they don't, the incidents make the news. Stacks that include OpenAI, Anthropic, or any foundation-model API introduce external dependency on pricing, availability, model deprecation, and terms-of-service changes the client has no influence over. The risk is real, and it is being taken on behalf of the client without being named.
Applied R&D asks a different first question. Not where can we put AI in this, but what is the smallest, most understood, most inspectable system that actually solves this problem? Sometimes the answer involves an LLM. Often it is a well-designed database query, a clear workflow, a piece of hardware specified for the environment it will live in, or a process refinement that does not require code at all. The discipline is in knowing which.
Failure mode three: quality is the first thing to go
The third failure mode is the one that costs the most and is the hardest to see at handover.
When the commercial promise is audit to deployment in weeks, something has to give, and what gives is the work that does not demo. Tests. Error handling. Observability. Structured logging. Rollback procedures. Idempotency. Retry logic. Dead-letter queues. Load testing. Documentation that a new engineer can actually read. All of this is invisible to a demo user and indispensable to an operations team.
The no-code glue layer that powers many modern agency builds — Make.com, Zapier, n8n — is a particularly instructive case. These tools are excellent for certain kinds of work, and they are entirely appropriate when used well. The problem is what happens when they are used as the substrate of a client-facing system and the vendor moves on.
The workflows exist in accounts the client may or may not own. The API keys are stored in fields that are not obvious to audit. The logic is distributed across dozens of small visual boxes with no version control and no code review. Changing anything requires someone who knows which box does what, and that person was the engineer who left. The automation works until one of thirty upstream services changes an API response, and then it fails quietly, and then it fails loudly, and nobody can tell which.
This is not a failure of the tools. It is a failure of engineering discipline. A serious build uses no-code where no-code fits, real code where real code is warranted, and documents the difference. A rushed build uses whatever ships fastest and tells the client it was a feature.
The common root
These three failure modes share a single cause. The business model rewards speed of shipping and aesthetic of deliverable, not quality of ownership. When a firm's commercial promise is measured in weeks-to-ROI, the work that makes a system safe, sound, and durable is the first thing cut. There is no room in the timeline for it.
The AI boom has produced a category of agency that is structurally optimised for the sale, not the engineering. The sales cycle is optimised. The deliverable is optimised. The client is left holding the risk.
How we build instead
Slash Tech is an applied R&D company. That phrase does real work. It means we take longer, ask more questions, and spend more of the engagement on thinking than on shipping. It means the first conversation we have with a client is not a thirty-minute audit — it is a Discovery Sprint, because most operational problems cannot be understood in half an hour, and pretending otherwise is the first failure.
It means we use AI where AI genuinely makes the system better, and we use boring, well-understood tools everywhere else. It means we treat security as a design constraint, not a milestone, and we say so upfront when the work the client is asking for carries more risk than the timeline they are asking for. It means the systems we hand over are built to be owned — tested, documented, instrumented, auditable, and legible to a competent engineer who was not in the room when they were written.
The systems we build ship more slowly. They also break less often, handover cleaner, and still make sense to their owners a year after we are gone.
That is not the fastest promise on the market. It is the one that still holds after the demo is over.