You've got a SaaS contract renewal coming up. Could be three months away, could be six. The procurement process is starting to rumble. Someone's pulling together the business case for renewal. The vendor's already sent their "valued customer" email with the new pricing (higher, obviously).
Here's my challenge to you: before you sign anything, spend two weeks trying to build the thing yourself.
I'm serious.
Not a full replacement. Not a production-ready system. Just a focused sprint where your team attempts to build the core 20% of what you actually use.
The worst that can happen? You learn something.
The best that can happen? You cancel the contract and never look back.
Either way, you win.
"But We Can't Build Software"
Yes, you can.
I don't know your organisation, but I know this: you have people who understand the problem you're solving. You have people who use the current software every day and know exactly what's wrong with it. You probably have people who've taught themselves Excel macros, cobbled together automations, or built workarounds because the official tools don't cut it.
That's capability. It's just never been pointed at the right target.
The tools to build software have changed dramatically. AI-assisted development means someone with domain expertise and basic technical literacy can create functional applications in days. Not toys, real tools that solve real problems.
You're not starting from zero. You're starting from deep knowledge of what you actually need, which is worth more than any technical skill.
The Two-Week Challenge
Here's what I'm proposing:
Week 1: Define and Design
Gather the people who actually use the software daily. Not the executives who signed the contract, the humans who live with the consequences.
Ask them:
- • What do you actually use this software for? (Be specific. List the workflows.)
- • What percentage of the features do you touch? (It's lower than you think.)
- • What's frustrating about it? (Let them rant. Take notes.)
- • If you could only keep three capabilities, what would they be?
You'll discover that you're paying for a hundred features and using twelve. The software does fifty things adequately when you need it to do five things brilliantly.
Now sketch what a focused alternative might look like. Not comprehensive, just the core. What would a tool built specifically for your needs include? What would it leave out?
Week 2: Build a Prototype
Take your best sketch and try to build it.
This doesn't require a development team. One or two people with curiosity and access to modern AI tools can make surprising progress. Use Claude, use ChatGPT, use Cursor, use whatever helps. The AI handles the technical scaffolding; your people provide the domain knowledge.
Set a hard boundary: two weeks, then stop and evaluate. This isn't about building a production system. It's about learning what's possible.
What You'll Discover
Even if your prototype is rough, even if it's barely functional, you'll learn things that transform your position:
You'll understand your requirements properly.
Nothing clarifies what you need like trying to build it. Vague desires become specific features. "It should be easier" becomes "we need these three fields on one screen instead of four clicks."
You'll see what's actually hard and what's not.
Some things you thought were complex turn out to be straightforward. Other things you assumed were simple reveal hidden complexity. This knowledge is power in any vendor conversation.
Your team will develop new skills.
Even a failed attempt teaches people how to think about building. They'll understand systems better. They'll ask better questions. They'll stop accepting "that's just how software works" as an answer.
You'll know if building is viable.
Maybe you'll discover that your specific problem is genuinely complex and vendor software makes sense. That's fine, at least now you know why you're paying for it. Or maybe you'll discover that 80% of what you need is shockingly achievable.
The Vendor Conversation Changes Completely
Let's say you do this exercise and decide the SaaS still makes sense. You haven't wasted anything, you've transformed the negotiation.
Before the exercise:
You were a passive buyer. The vendor showed you their roadmap. You asked if they could add features. They said "great suggestion, we'll consider it." You signed the renewal because what choice did you have?
After the exercise:
You're an informed buyer. You know exactly what you need. You can ask hard questions: "Why does this require four clicks when we built a prototype that does it in one?" You can push back on pricing.
You might negotiate a better deal. You might drop to a lower tier. You might get concessions the vendor never offers to passive customers.
Or you might realise the vendor can't actually give you what you need, and you should build after all.
Either way, you're no longer negotiating from ignorance.
The Real Worst Case
People worry about failure. "What if we try to build and it doesn't work?"
Then you've spent two weeks learning. Your team has new skills. You understand your requirements better than ever. You have concrete evidence about what's hard and what's easy.
That's not failure. That's investment.
The real worst case is what most organisations do:
Renew the contract without questioning it, pay more than last year, use the same 15% of features, and repeat the cycle forever.
Every renewal without examination is a choice to stay dependent. Every year you don't build capability is a year your competitors might be building theirs.
The risk isn't trying and failing. The risk is never trying at all.
"What If It Actually Works?"
Here's the outcome nobody talks about: what if your two-week prototype is actually good?
I've seen this happen. A team sets out to "just learn" and accidentally builds something better than the software they were paying six figures for. Not because they're geniuses, because they understand their problem in a way no vendor ever could.
Generic SaaS is built for the average customer. It has to serve thousands of organisations with different needs, so it serves none of them perfectly. Your prototype is built for exactly one customer: you. It can be opinionated. It can ignore edge cases that don't apply. It can do the specific thing you need brilliantly instead of doing everything adequately.
When your scrappy prototype outperforms the polished vendor product, it's a revelation.
The whole mythology of "we need enterprise software" collapses.
You realise you've been paying for complexity you don't need, maintained by people who don't understand your problems.
The renewal conversation becomes very different when you have a working alternative.
How to Actually Do This
Let me be practical about execution:
Pick one system to challenge.
Don't try to replace your entire software stack. Choose something contained: a tool that frustrates people, a contract that's coming up, a system that does way more than you need.
Assemble a small team.
Two to four people who understand the problem domain. At least one person with technical curiosity (doesn't need to be a developer). Someone with authority to make decisions without escalating everything.
Protect their time.
This won't work as a side project squeezed between meetings. Block two weeks. Shield them from business as usual. Make it clear this is a priority.
Set clear boundaries.
Two weeks, then stop and evaluate. Not "keep going until it's perfect." The goal is learning, not launching.
Document everything.
What worked, what didn't, what you learned. This becomes valuable regardless of outcome.
Be honest about the result.
Maybe you'll build something great. Maybe you'll confirm the vendor is worth the money. Maybe you'll discover you need something different entirely. All of these are good outcomes.
What We Do
This is exactly what Teachnology helps with.
We work with organisations who are ready to challenge their assumptions about building versus buying. We help them run these experiments, develop capability, and make informed decisions about technology.
And we don't bullshit.
If your prototype shows that the vendor software genuinely makes sense, we'll tell you that. We're not here to sell you on building for building's sake. We're here to help you make good decisions based on actual evidence.
If building makes sense, we'll help you do it properly, not just prototype, but production-ready. We'll help you develop internal capability so you're not dependent on us forever.
If you need something in between (build some things, buy others) we'll help you figure out which is which.
We call a spade a spade. Sometimes that means telling clients things they don't want to hear. That's the job.
The Question You Should Ask
Your renewal is coming up. Before you sign, ask yourself:
Have we ever seriously tried to build an alternative?
Not thought about it. Not discussed it in a meeting. Actually tried. Hands on keyboards. Real attempt.
If the answer is no, you don't actually know whether you need that software. You're renewing out of habit, not evidence.
Two weeks. One focused experiment. That's all it takes to find out.
What's the worst that can happen?
Written by
Jason La Greca
Founder of Teachnology. We help organisations build capability instead of dependency, and we're honest about when that makes sense and when it doesn't.
Connect on LinkedInGot a renewal coming up?
We can help you run this experiment properly, and be honest about what we find.
Get in TouchNot sure where you stand?
Take the AI Readiness Assessment to see your organisation's capability baseline.
Start Assessment