Introducing tfMakers: building with AI, without the pitfalls

I've spent the last couple of years watching AI change how our own studio works, and the part that excites me most is what it does for the businesses around us. Almost every one of them has a list of things it has always wanted built, and AI has made that list affordable: the internal tool that would once have needed a project, a budget and a quarter of somebody's time can now be in front of the people who need it within weeks.

tfMakers is how we put that within reach of businesses that don't have an AI team of their own, and don't want to spend a year hiring one. I'm genuinely excited about it, and I think the businesses that start building this way now are going to find it hard to imagine working any other way.

What tfMakers is

A tfMakers pod is a small team of innovators, engineers, designers and automation specialists who join yours, work on your problems with your systems, and build alongside your people. We use AI throughout the build, so things get made quickly, and every pod is led by people who have been shipping and running production software for years, so what gets made is safe to run. You see a working prototype within two weeks, and what you end up with is yours to keep.

What a pod can build

Every business is different, which is rather the point, but the first conversations tend to land on the same kinds of things:

• Workflow automations that route approvals, requests and handovers between your tools and your people, and chase whatever gets stuck.
• Internal tools, dashboards and portals for staff, partners or customers, built around the way your team actually works.
• Connected systems, so data moves between the tools you already pay for without anybody copying it across.
• Document processing that reads invoices, claims and forms, checks them against your rules and files them where they belong.
• Reporting that builds itself from the systems you already run.
• AI agents that answer customers and staff from your own systems and policies, with the source attached.

Some of these have AI working inside them and plenty are straightforward tools and automations. What they share is that each is the kind of thing a pod can put in front of you as a working prototype in two weeks.

Three ways to work with us

Most clients start with a Sprint, a two-week cycle that puts a working prototype in front of you, so you can find out quickly whether an idea is worth spending more on. Once something has proven itself, a Swarm puts more people on it and builds it into the business properly: connected to your systems, secured, tested and handed into everyday use. When the work keeps coming, a Hive embeds a team with yours for the long run, working through a shared roadmap at a pace you can plan around, and it's the most cost-effective of the three when there's a steady stream of things to build.

Why it takes more than AI

Anyone can build with AI now, and I think that's wonderful. It also means the pitfalls are spreading as fast as the tools, and in the same week we were putting the finishing touches on tfMakers, MyBroadband reported on a South African coffee franchise that had found this out the hard way.

Its chief executive had spent six weeks of evenings and weekends building an internal dashboard with an AI coding assistant, which is exactly the kind of initiative I'd love to see more of. The dashboard ran on a public host, and when staff posted photos of their laptop screens on Instagram with its address visible, somebody looked it up and found that the login screen in front of the data was protecting nothing. The data had been sent to the browser along with the login page, so anyone who opened the page source could read it. MyBroadband verified contact details linked to 132 locations, along with performance and financial figures, and the app came down after they asked about it.

The AI most likely did exactly what it was asked, which was to build a dashboard with a login. Nobody asked it where the data should live or who should be allowed to see it, and a tool that writes plausible, working code will rarely raise the questions nobody put to it. That gap, between something that works and something that's safe to run, is exactly the one tfMakers is built to close.

Why not just build it yourself?

Sometimes you should, and I'd rather say so plainly. If the data is made up, the users are you and a colleague, and nothing breaks if it disappears, building it yourself with an AI assistant is fast, cheap and a brilliant way to find out whether an idea deserves more.

The line is crossed the moment it touches something you can't afford to lose or leak: customer or staff details, money, the systems your business runs on. From there the question stops being whether it works and becomes whether it's safe, and skipping the people who know how to answer that is where the pitfalls come from:

• Data that leaves the server before anybody has proved who they are.
• Passwords, keys and tokens written into code that ships to every visitor's browser.
• No tests, so nobody knows what the next change will break.
• Personal information handled without the safeguards POPIA expects.
• Nobody owning the tool once the person who built it moves on to the next idea.

The usual alternatives have their own problems, which is why so many leaders end up building it themselves in the first place: hiring an engineering team takes months, and a traditional project can take longer to scope than the tool would take to build. I wrote about the commercial side of this in When building it yourself is the slower option, and the short version is that buying a team can be faster than building one, as long as that team works inside your business.

Where tfMakers steps in

tfMakers gives you the speed of building with AI and the engineering that lets you rely on what gets built. A pod moves at the pace a motivated leader manages on their own, and every part of what it builds is checked before it goes anywhere near live data:

• Access controlled on the server, so data stays put until somebody has proved who they are, and then only what they're allowed to see is sent.
• Secrets kept out of the browser and out of the code that ships.
• Tests and monitoring, so a change can't quietly break something and a problem reaches us before it reaches anybody else.
• Personal information handled with POPIA in mind, with permissions and review designed in from the start.
• Connections into the systems you already run, with proper logging, so the new tool never ends up in a corner nobody looks after.
• The same people around after launch, so somebody is accountable when it needs to change.

If you've already built something yourself, that's a great place to start. A Sprint can look at what you have, find what it gives away and work out with you what it would take to run it safely, and a Swarm can take it the rest of the way. The way we check the work is in What we mean when we say AI-native, if you'd like the detail.

Start with a Sprint

AI has made building accessible in a way that was hard to imagine five years ago, and I can't wait to see what our pods build with the businesses we work with next. If you have a list of things you'd love built, something half-built you'd like to make safe, or an idea you want to test quickly, a two-week Sprint is a low-commitment way to start.