Find the expensive problems before you commit to a build.
You're planning a new platform or a rebuild, and have a set of technical decisions in front of you that you have no way to judge.
Maybe there's a designer involved, or a frontend already built, and now you need to work out what sits behind it. You have a dozen tabs open comparing Supabase, Firebase, Xano and AWS, and no way to tell which comparisons you can rely on.
You need to know which of those options fits your situation.
Most developers will recommend the stack they work with, or one they want to try. That may be a reasonable choice, but researching alternatives isn't usually part of the work you're paying them to do.
I'll do that research on your behalf, identify the risks and gaps, and give you a recommendation you can use to decide what happens next. I don't implement what I recommend.
First, work out whether you need custom software at all.
I try to talk clients out of custom builds because they're a bigger commitment than most people expect. Once you have people depending on your software, you have taken on an ongoing responsibility to keep it fast, secure, and available. The ongoing costs may surprise you.
Often, you can get the workflow you need by configuring existing products and building a small integration between them. Sometimes the urge to build comes from frustration with a current tool, and proper configuration can solve it.
A custom build may be necessary when the software enables an innovative process.
We'll work out whether a custom build is needed in the first stage.
I'll work with your company over 3-4 weeks to fully understand what you're trying to achieve. We'll work through the decisions together as the assessment progresses.
The roadmap has a fixed fee of AUD $9,500 ex GST.
AWS, Laravel and Postgres are my usual starting point. I've used that combination for years, and it provides much of what a typical application needs which saves time on implementing common functionality.
I lean toward using the "boring" options. Choosing widely supported technology helps you avoid vendor lock-in, keep costs predictable and makes hiring easier.
Yes, there are some very popular stacks that you'll see recommended on social media because they enable rapid development. These services and tools are often optimised for small projects and prototypes, but introduce scaling and budget challenges as the software grows.
So my rule of thumb is public cloud plus open source, except where a SaaS product is a smaller part of your stack and pays for itself in reduced maintenance and configuration costs. Algolia for search is a good example of this.
I'll assess whether those defaults fit your situation and recommend alternatives where they don't.
The most important architectural decisions are the ones that are expensive to reverse once implementation has begun.
It's things like getting the data model right with respect to tenancy, entity ownership, the user and organisation hierarchy; and how frequently changing data will be used in user-facing reports. Compliance requirements also affect the design, so data sovereignty, encryption and GDPR obligations need to be considered from the start.
Spending a few weeks on these decisions before development can help you avoid an expensive rebuild later. Even with AI tooling at your disposal, these types of rebuilds are costly, time-consuming and risky, especially when it comes to data migration.
Other choices are relatively easier to change later, including the application framework, frontend, database engine and most third-party providers. You can spend less time on these now, particularly where an interface separates them from the rest of the system.
Client story
A client had an MVP but serious doubts about its quality. I reviewed the code and recommended a total rebuild.
I mapped out the tech stack and wrote core user stories to explain the system's key attributes and data models. That gave the rebuild a defined technical direction and a description of what the system needed to do.
Do you write any code?
No. You'll receive an architecture assessment and roadmap document.
I already have a developer. Is this still useful?
Yes, and it's often more useful when you do. The document will give you an independent view of
the decisions and risks, and the handover call lets your developer ask
questions about the reasoning and open issues.
What if I already have designs or a frontend?
I'll review what you already have and use it as evidence when assessing
the proposed approach. Send it through before we talk.
What if I'm not sure I need a roadmap?
Tell me what you're trying to do and which decisions you're stuck on.
We'll discuss whether a roadmap would help before agreeing to any work.
If you only need help with a specific question, an
Advice & Unblocking session may be enough.
What is an architecture roadmap?
It is an independent assessment of the technical direction for a new
platform or rebuild. It explains whether the proposed approach fits
your goals and constraints, what could go wrong, and what to resolve
before committing to development.
Is this a requirements or product discovery project?
No. I'll work through enough of the requirements and main workflows to
assess feasibility, risks and technical direction. I don't produce a
complete product specification, backlog or screen-by-screen design.
Can you create an architecture roadmap for a rebuild?
Yes. A rebuild is still a new technical design, but the existing
application gives us evidence about what to keep, what to change and
what needs to be understood before work begins.
Does the roadmap include wireframes or a database schema?
Those are not standard deliverables. I may use a diagram, example
workflow or data structure when it helps explain a recommendation, but
the engagement is focused on decisions and risks rather than a complete
implementation specification.
Will you explain the roadmap to our developer?
Yes. After the client walkthrough, I'll hold a separate handover call
with your chosen developer or agency. We'll cover the reasoning,
assumptions, risks and open questions. Further advice during the build
is available through Backchannel.
Can I get you involved once the build starts?
You can use Backchannel to ask architectural
questions as your team builds the software. I won't be implementing
the recommendations.
If your question is smaller than a full roadmap, Advice & Unblocking is a single call with a written summary afterwards. Plenty of people start there and find that's all they needed.
If you already have a system running and want it examined rather than designed, the technical assessments are the better fit.