I keep seeing people talk about custom software as though using Supabase, Stripe, AWS or an authentication provider somehow disqualifies it from being custom.
The argument usually goes something like this:
“Even companies with large IT teams still use off-the-shelf and enterprise software.”
This is presented as a gotcha.
It is actually a description of software development.
Nobody orders a custom kitchen and then complains that the carpenter did not forge every screw.
Custom software means the finished product is built around your business. It does not mean somebody has to create a database engine, payment network, cloud platform and authentication system from scratch before they are allowed to call it custom.
This is not a competition to see who can rebuild modern computing with the least sleep.
I have no desire to invent password security
I use Supabase Auth in our projects.
That means Supabase provides established machinery for handling things like authentication, sessions, tokens and external login providers. It does not mean Supabase built the application.
I have also seen the wonderfully dramatic claim that developers using Supabase are sending unencrypted requests over the open internet.
No, we are not.
Supabase’s HTTP APIs, including Auth, Storage and its database API, automatically enforce SSL. The information travelling between the application and those services is encrypted in transit.
Direct connections to Postgres are a separate matter. Supabase supports SSL for those connections and lets developers reject connections that are not using it. Its own production checklist tells developers to turn on SSL enforcement before launch.
Of course somebody can configure a direct database connection badly. They can expose a service key too, disable security controls or give every user access to everything.
If somebody does that, blame the person who did it. Do not invent a new feature of Supabase where it apparently throws everybody’s data naked onto the internet.
I use Supabase Auth because I have no desire to turn a client’s passwords into a personal research project.
I still have to decide:
- Who is allowed to create an account
- What each type of user can see and do
- How permissions work inside the product
- Whether one customer can ever access another customer’s data
- What happens when somebody changes role or leaves the company
- Which actions require extra verification
- What gets recorded when something important changes
Those decisions are specific to the application and the business using it. They are part of the custom work.
What I am not doing is sitting at my desk thinking, “Password hashing seems easy enough. Let me have a go.”
I am not writing my own encryption to prove I am a real developer either. Security professionals have suffered enough.
The NIST Secure Software Development Framework explicitly recommends reusing existing, well-secured software when practical instead of duplicating functionality. It considers this especially important for security-related components.
Not exactly the reckless bedroom-coder manifesto some people would have you imagine.
Supabase can still be configured terribly
Established services remove an enormous amount of work. They do not stop somebody from making awful decisions while connecting them.
Supabase lets developers control access to data using Row Level Security. Those policies determine which database rows a user is allowed to read, create, change or delete.
The policies need to be written and tested properly.
Supabase’s documentation explains that frontend access depends on Row Level Security being enabled and correctly configured. It also warns that secret and service-role keys can bypass those protections and must never be exposed in frontend code.
Supabase provides the controls. It cannot climb out of the dashboard and slap your hand when you configure them badly.
This is where some AI-built applications become terrifying.
The AI says the integration is complete. The application loads. The developer creates one account and sees the correct dashboard.
Nobody attempts to access another account’s records. Nobody changes the user ID inside a request. Nobody calls the database outside the friendly little interface they just built. Nobody checks whether a normal user can perform an administrator action.
They have tested whether the application works while being used politely.
Attackers are rarely known for their manners.
This is not evidence that Supabase is reckless. It means the person connecting it did not know what needed to be tested, and the AI was never going to interrupt the celebration to ask whether they had tried stealing another user’s data.
Every custom product contains things somebody else built
A modern application may use:
- A managed database
- An authentication provider
- A payment processor
- A cloud hosting platform
- An email delivery service
- An error-monitoring service
- Open-source frameworks and libraries
- APIs belonging to other platforms
Even the companies providing those services depend on operating systems, networking infrastructure, hardware and software produced by other companies.
Software is layers of other people’s work. Anyone pretending otherwise is either selling a fantasy or has never looked very far below the framework they use.
The actual job is choosing suitable components, connecting them correctly and understanding exactly where each provider’s responsibility ends.
Stripe operates its payment infrastructure. I still need to make sure the correct customer is charged the correct amount, failed payments are handled properly and nobody can change a price by editing a request.
Supabase operates its authentication service. I still need to design the permissions and business rules surrounding each authenticated user.
The cloud provider operates the underlying infrastructure. I remain responsible for what gets deployed, which credentials it can access and whether anybody notices when it begins behaving strangely.
Putting several reputable logos on an architecture diagram does not fill the gaps between them.
“Built with” is not the same as “built by”
People see “Built with Supabase” or “Hosted on AWS” and assume the product was mostly supplied by those companies.
By that logic, a restaurant did not make your dinner because it used an oven manufactured elsewhere.
The custom value is usually in the business-specific layer:
- The workflows your team actually follows
- The relationships between your data
- The rules governing who can do what
- The integrations with the systems you already use
- The automation that removes repetitive work
- The interface your customers or staff interact with
- The reports and decisions the product makes possible
Those are the parts that make one application meaningfully different from another.
Rebuilding authentication from scratch would not make that work more custom. It would take time and money away from the product your business asked for so somebody could cosplay as an authentication company.
AI should not be choosing the entire stack for you
I am not suggesting that developers should accept whichever collection of tools somebody is currently shouting about, or let AI choose the entire tech stack from a three-sentence description of the project.
AI is perfectly happy to recommend a stack with complete confidence.
It does not know about the requirements you forgot to mention. It does not know which constraints you have failed to identify. It does not know that your reassuring little “internal tool” will suddenly be given to four hundred customers after somebody decides it looks ready.
Ask the same question slightly differently and it may confidently recommend another stack.
AI can help research options, compare documentation and find problems with a proposed approach. I use it for exactly that. The final decision still needs to come from somebody who understands the project and can defend the choice without reopening the chat that produced it.
“ChatGPT said this stack would be good” is not an architectural decision.
It is barely a sentence.
Managed services still come with baggage
Choosing a third-party service creates questions that will not fit inside a cheerful build-in-public update.
What happens if the provider changes its prices? Can the data be exported? How difficult would migration be? Is the service appropriate for the type of information being stored? Where is the data hosted? Which parts of the application stop working during an outage? Who owns the accounts?
There are also updates, vulnerabilities and breaking changes to watch.
NIST’s guidance recommends tracking external components and monitoring them for known problems. Reusing established software is sensible. Installing it, announcing the launch and immediately losing interest is not.
Some components should be built specifically for the project. Others would be ridiculous to build ourselves. Most custom applications contain a mixture of both.
There is no single “custom or off-the-shelf” decision. Each component needs its own answer, preferably from somebody who can explain why they chose it.
What I would ask before approving a custom build
If you are paying someone to build software for your business, ask which parts will be custom and which services they plan to use.
Then keep asking:
- Why did you choose those services?
- Who will own the accounts?
- Can we export our data?
- How are user permissions enforced?
- How will those permissions be tested?
- Which credentials exist, and where are they stored?
- What happens if one of the providers becomes unavailable?
- Who monitors updates and security advisories?
- How difficult would it be to replace a provider later?
A competent developer should be able to answer in normal language.
If the explanation collapses into fashionable terminology, ask again when they do not have an AI chat open beside them.
The word “custom” is not a dare
I do not need to invent a database to design a sensible data model. I do not need to create an authentication protocol to implement proper access control. I do not need to process credit cards myself to build a reliable payment flow.
I will happily use Supabase, Stripe and every other established service that earns its place in the project.
Then comes the part that never looks impressive in a launch post: configuring permissions, testing abuse cases, documenting dependencies, watching the logs and continuing to maintain the application after everybody has finished congratulating themselves.
Anybody can generate a dashboard and list the fashionable services in their stack. When the permissions fail, a provider changes something or one customer sees another customer’s data, those logos will not explain the system for them.
At that point, the person who built it either understands what they connected or starts frantically opening new AI chats.