If you found this page because thinknew.nz sent you here — that’s intentional. Let me explain.
Think New has been my business for over ten years.
That’s not a footnote. That’s a decade of early mornings and late nights, of client calls and code pushes, of problems solved and lessons learned the hard way. Think New is how I built a career, how I learned what I was capable of, and how I met most of the people I’m proud to call clients.
So before anything else: thank you. If you worked with Think New, you trusted me with something that mattered to you. I don’t take that lightly, and I never did.
That’s a decade of early mornings and late nights.
Here’s what changed — and I want to be honest about how it happened, because it wasn’t a grand strategy. It was a gradual realisation.
For years, I built integrations the way most developers do: I understood the system deeply, I made it work, and I became the person you called when something went wrong. That felt like value. In a lot of ways, it was value.
But I kept noticing something that bothered me.
The clients who were best served weren’t the ones who needed me most. They were the ones who needed me least — because the systems we’d built together had given them visibility, control, and confidence to handle things themselves.
The clients who were worst served were the ones who couldn’t do anything without a call to me first. Not because they weren’t capable. Because the systems we’d built had made them dependent.
That’s not a tech problem. That’s a fit problem.
I started asking a different question. Not “does this work?” but “does this fit?” Not “can I build this?” but “will this give them control, or will it give me control?”
The answer to that question changed how I build things. And eventually, it changed the name on the door.
The clients who were best served weren’t the ones who needed me most.
I want to show you what I mean with two real examples, because this is easier to understand in the concrete than in the abstract.
The system went from static and supplier-dependent to dynamic and owner-managed.
TrustTech.
I chose it carefully. Trust because the relationship between a business and its technology should be one of confidence, not dependency. Tech because that’s what we actually do — we build things that work.
But underneath the name is something simpler: I believe technology should put control back in the hands of the people running the business. Not the developer. Not the platform. The owner.
That belief didn’t start with TrustTech. It was always there in the Think New work, building quietly. TrustTech is just what happens when you let that belief run the whole show.
The email address has changed. The legal name has changed. What hasn’t changed is the person building things, the care that goes into the work, and the standard I hold myself to.
Technology should create independence, not dependency.
I’m still here. Same phone. Same commitment. Just a clearer sense of what I’m building toward.
If you’re an existing client, nothing about our relationship changes unless you want it to. Your projects are still mine, your trust is still something I take seriously, and I’m still the person who picks up the phone.
If you’re curious about what TrustTech is building now — there are three things I’m proud of and happy to talk through when the time feels right:
None of those are a sales pitch. They’re just what I’ve been building, and I think some of them might be useful to people I already know.
If any of it resonates, you know where to find me.
— Matt