Five months ago, neither of us could code.
Not "we weren't very good at it." Not "we'd done a bit in university." Genuinely could not write a line of production-ready code.
Today we're running a software agency building custom applications and AI operating systems for established businesses. Real clients. Real money. Real production systems that companies rely on.
This sounds insane when you say it out loud. And it kind of is.
But it's also the thing that makes us different from every other software consultancy or development agency you'll talk to.
Here's what actually happened, what we learned, and why it matters if you're considering working with us.
The problem we were trying to solve
We didn't set out to become developers.
We were operations consultants. We'd work with established businesses to identify inefficiencies, map processes, design better systems. We were good at it.
The problem was implementation.
We'd figure out exactly what a client needed - custom integration here, automated workflow there, maybe a purpose-built application for this specific thing they do. Then we'd hand it to developers to build.
And that's where it would fall apart.
The developer would build exactly what we specified. But they didn't understand why it needed to work that way. So when they hit a technical constraint or found a simpler implementation, they'd make a call that made sense from a development perspective but broke the business logic.
Or we'd realize mid-build that we'd specified the wrong thing because we didn't understand what was technically possible.
The gap between "person who understands the business problem" and "person who builds the solution" was killing projects.
We looked for people who could bridge that gap. Developers who understood operations. Business people who could code.
We couldn't find them. Or when we did, they were working for McKinsey or building their own startups, not available to us.
So we made a stupid decision: we'd learn to do both ourselves.
The first three months were humbling
We started in September 2024.
Nick had done a bit of Python for data analysis. I had done literally nothing. We were starting from scratch.
We picked up JavaScript, TypeScript, React. Learned how APIs work. Figured out databases. Tried to understand what the hell a webhook was and why everything seemed to use them.
It was brutal.
Not because the concepts are impossibly hard, but because there's so much assumed knowledge. Every tutorial assumes you know ten other things already. Documentation is written for people who don't need documentation.
We'd spend four hours trying to get something working, only to discover we'd missed a semicolon or were using the wrong version of a library or had a port conflict we didn't know existed.
But we kept going, because we had clients waiting.
Our first real project was a proposal automation system for ourselves. We needed it, nobody else was building it for us, so we'd build it ourselves.
It was terrible. The code was a mess. The error handling was non-existent. It worked, barely, and we were terrified it would break.
But it worked.
Month four: the breakthrough
Something shifted in January.
We stopped trying to learn everything and started pattern matching.
Most business software isn't rocket science. It's data going in, logic happening, data coming out. Forms, databases, APIs, integrations, workflows.
Once you understand the patterns, you can build anything. You're just combining patterns in different ways.
We built our second client project - a custom dashboard for a property development company. They had data in three different systems. They needed one place to see everything. Simple, conceptually. Not simple to build.
But we built it. And this time the code wasn't terrible. It was actually... pretty good.
The breakthrough wasn't technical. It was realizing we didn't need to be expert developers. We needed to be expert problem solvers who could write code.
There's a difference.
What we learned that actually matters
Here's what five months of going from zero to production taught us:
1. Most software is over-engineered for what businesses actually need
Developers love elegant solutions. Scalable architecture. Sophisticated patterns.
But most businesses don't need software that scales to a million users. They need software that works reliably for 50 users and solves a specific operational problem.
Coming from operations first means we build the simplest thing that actually solves the problem. Not the most technically impressive thing. Not the most scalable thing. The thing that works.
2. Integration is always harder than people think (including us)
Every vendor says their API is "easy to integrate with." This is a lie.
APIs are documented for developers who already understand APIs. Rate limits aren't mentioned until you hit them. Authentication can be anything from simple API keys to OAuth flows that make you want to cry.
We learned this by integrating everything. Xero, HubSpot, Monday.com, Google Workspace, industry-specific platforms, legacy systems with barely-functional APIs.
The value isn't knowing how to integrate one specific platform. It's knowing that integration is always messier than it looks, and building in time and budget accordingly.
3. The best code is code you don't have to write
Because we can code now, we're very selective about when we actually write custom code.
Can we solve this with n8n workflows and some clever integration? Do that.
Can we solve it with Airtable or Supabase and some custom views? Do that.
Can we solve it by connecting two existing platforms with a webhook? Do that.
Only write custom code when you genuinely need something that doesn't exist.
This is the opposite of what most developers do. Developers like building things. We like solving problems. Sometimes building is the answer. Usually it's not.
4. Documentation is a client service, not a developer task
We document everything obsessively.
Not for ourselves - we know how the code works. For the client, for their team, for whoever inherits this system in three years.
Every project gets:
- Architecture diagrams showing how everything connects
- User documentation for the team who'll use it
- Technical documentation for whoever maintains it
- Runbooks for common issues
- Video walkthroughs of key workflows
This comes from being on the client side. We know what it's like to inherit a system with no documentation. We know how frustrating it is when the only person who knows how something works leaves.
So we build systems that outlast us.
5. Being new to development is actually an advantage
We don't have developer ego.
We're not attached to specific technologies or frameworks. We don't care about using the newest, coolest thing. We don't get into religious debates about languages or architectural patterns.
We just want to solve the business problem with the least complicated, most maintainable solution possible.
This makes us pragmatic in ways experienced developers often aren't.
Why this matters if you're considering working with us
Most software agencies have one of two problems:
Problem 1: They understand technology but not operations
They'll build you exactly what you ask for. If you ask for the wrong thing, they'll build that too. They're order-takers, not problem solvers.
Problem 2: They understand operations but can't build
They're consultants who hand off to developers. The gap between understanding and implementation creates delays, misalignment, and solutions that don't quite work.
We're both.
When we're in a discovery session, we're thinking about technical architecture. When we're writing code, we're thinking about operational impact.
This integration happens in real-time, in the same conversation, often in the same brain. There's no handoff. No translation layer. No game of telephone.
When you describe your business problem, we're simultaneously:
- Understanding the operational pain point
- Mapping the systems involved
- Identifying integration opportunities
- Assessing technical feasibility
- Estimating build complexity
- Considering maintenance implications
We can do this because we came from operations and learned to build, not the other way around.
What we do
We don't build complex distributed systems. We don't optimise for microsecond performance gains. We're not writing low-level algorithms or building gaming engines.
We build business software for established companies. Custom applications, AI operating systems, system integrations, workflow automation.
That's a specific domain. We've gotten very good at it very quickly because we focus.
Are there old-school enterprise computer science engineers with more technical depth? Absolutely.
Are there many who understand business operations as well as we do and can build production software? Not many.
The consulting-development gap nobody talks about
Here's the thing about traditional software consulting:
The consultant understands your business. They design a solution. They write a specification. They hand it to developers.
The developers build to spec. When they hit problems, they make decisions. Those decisions make sense from a code perspective but might break the business logic.
Nobody notices until implementation. Then you're troubleshooting why the system doesn't work the way you expected, even though it matches the spec perfectly.
This gap costs businesses thousands of dollars and months of time.
We don't have that gap. When we design a solution, we're thinking about how we'll build it. When we build it, we understand why it needs to work that way.
If we hit a technical constraint, we don't just solve the technical problem. We think through the operational implications and adjust the design accordingly.
This is only possible because we're both consultant and developer. Architecture and builder. Strategy and execution.
Why we're telling you this
Most agencies would hide this story. "Five months ago we couldn't code" isn't exactly a confidence-inspiring message.
But we're telling you because it's the truth, and because it's actually our competitive advantage.
We learned to build software because we needed to solve business problems and couldn't find anyone who understood both sides.
That origin story shapes everything we do:
- We're operations-first, technology-second
- We build the simplest thing that works
- We integrate before we build
- We document obsessively
- We have no developer ego
We're not trying to impress you with technical complexity. We're trying to solve your operational problems with the right combination of integration, automation, and custom development.
If you want the most technically sophisticated solution, we're probably not your agency.
If you want the solution that actually works for your business with minimum disruption and maximum operational impact, let's talk.
What we're building next
We're five months into this journey. We're building increasingly sophisticated systems - AI knowledge bases, multi-platform integrations, custom dashboards, automated workflows.
Every project teaches us something new. Every technical challenge we solve makes us better at solving the next one.
But the core insight hasn't changed: the best solutions come from understanding the business problem and the technical constraints simultaneously.
That's what we do. That's what we'll keep doing.
And if you need software built by people who understand operations first and learned to code specifically to solve problems like yours, we should talk.
About ThinkSwift
We're a boutique creative software agency in Melbourne that builds custom AI operating systems and software for established businesses. We work with companies that have mastered their craft but need better operational systems to scale. If you're spending more time running systems than running your business, we should talk.
