You Built The Tool. Where Does It Actually Live?

On a Friday afternoon you finally built the thing. The one you filed a ticket for back in the spring: a page that pulls the open pipeline out of the CRM, scores every deal against the four signals that actually predict a close in your business rather than the ones the platform ships with, and writes the score back onto the record so the Monday meeting stops being an argument about whose export is current. It took about four hours. The engineering queue had quoted six weeks and the agency had quoted eight thousand dollars. It runs on your laptop, it is genuinely good, and you are sitting there with it open in a browser tab feeling slightly stupid about how long you waited.

Now what.

That gap, between a tool that works on localhost and a tool your team opens every Monday morning, is where most of these die. Not because the code is bad. Because shipping it turns out to be a different job than building it, and nobody mentioned that the second job has exactly two hard questions in it, neither of which is the one you are probably worried about.

The answer, before the reasoning

Put the login your company already owns in front of it, and give the app no data of its own.

That is the whole answer. Hosting, the part everyone frets over, is twenty minutes and twenty dollars a month, and I will get to why the free version of it is a trap you are probably already sitting in. But hosting is not the decision. The decisions are who can open the thing and whether it is allowed to become the only place a number lives. Get those two right and the tool is boring, which is the highest compliment internal software can receive. Get either one wrong and you have not built an asset, you have built a liability with a URL on it.

Both decisions get made before you deploy. Both are cheap when you make them on purpose and expensive when you make them by default.

Hosting is easy, and the free tier is not what you think it is

Start with the twenty dollars, because it is the smallest problem and it illustrates the shape of every other one.

You will deploy to a free tier. Everybody does. It is one command, it is zero dollars, and it works. Then go read the terms you clicked through. Vercel's fair use guidelines are blunt about it: Hobby teams are restricted to non-commercial personal use only, and all commercial usage requires a Pro or Enterprise plan. Commercial usage is then defined as any deployment used for the financial gain of anyone involved in any part of the production of the project, and the guidelines call out the case specifically, "including a paid employee or consultant writing the code."

You are a paid employee. You wrote the code on company time to make the company money. The internal tool is commercial usage by the vendor's own definition, which was last updated on the 29th of July, so this is not some dusty clause nobody enforces.

The fix costs twenty dollars a month for a developer seat on Pro, and viewer seats for everyone else are free. It is not a real problem. What it is, is the exact shape of every problem in this category: the free tier is free because it assumes you are not a business, and the moment your team depends on the thing, you are operating under a different contract than the one you signed up under. Cheap is a posture, not a price. Every time you find yourself thinking "well, it's free," the next thought should be "free for whom, doing what."

Pay the twenty dollars. Move on. The interesting questions are still ahead of you.

The login you should not write

Here is where the afternoon goes sideways.

The instinct, once you realize other people need to open this, is to build a login screen. It is a natural instinct and the model will happily write you one in about ninety seconds, complete with a password field, a hashing library, and a forgot-password flow. Do not do it.

The reason is not that the code will be wrong, although it might be. The reason is that you just volunteered to run an identity system. You now own a table of your colleagues' passwords, which is a thing you have to protect and a thing you have to answer for. You own a reset-email flow, which means you own an email sender and its deliverability. And most of all you own the offboarding problem, which is the one that actually bites.

Picture it. Someone leaves in June. IT does what IT does: disables the Google Workspace account, revokes the badge, kills the VPN. Your tool has never heard of Google. It has its own little user table, and that person is still in it, and they still know the password, and the tool still has a live connection to your CRM. Nobody in the offboarding checklist knows the tool exists because the offboarding checklist was written by someone who does not read your commit history. That is not a hypothetical failure. That is what happens by default when a tool grows its own login.

The alternative is to not put the login inside the app at all. Put it in front of the app, at the network layer, where the company's real identity system already lives.

Cloudflare's free Zero Trust plan does this, and the numbers are on the pricing page: zero dollars, forever, up to a fifty user limit, and it includes Zero Trust Network Access, described there as granular identity and context based access to internal self-hosted, SaaS, and non-web resources. In plain terms, you point it at your Google Workspace or Microsoft directory and it stands in front of your tool asking for the company login before anything else loads. Your app never sees a password. It just gets told who arrived.

Two things fall out of that, and they are the good part. New hire on their first Monday gets the tool automatically, because they got a company account. Someone leaves and IT disables that account, and they are locked out of your tool the same hour, because there was never a second door. You did not write the offboarding logic. You inherited it from a process that already existed and that somebody else is paid to run correctly.

The same free plan includes connector software that, in Cloudflare's words, securely connects resources without a publicly routable IP address. That means the tool does not have to sit on the open internet to be reachable. It can run on a twelve dollar server, or a machine in the office, with nothing exposed.

Worth noticing what this costs elsewhere. Vercel's own pricing page lists SAML single sign-on as a three hundred dollar a month line item on the Pro plan. That is for your team's access to the deployment dashboard rather than for your app's users, and confusing those two is exactly how people end up buying the wrong thing. But the broader point stands: "put my company's login in front of this" is priced as an enterprise feature by the hosting layer and given away by the network layer, and most people never look at the second one because they went looking in the place they were already logged into.

Give the app nothing to lose

The second decision is the one that separates a tool from a dependency, and it is almost never discussed because it does not feel like a technical choice at all.

The moment your app is the only place some piece of information lives, you have created a system of record. Not metaphorically. You now owe that data backups, a migration path, a security answer when the questionnaire comes, and a named human who owns it. That human is you, indefinitely, including after you change jobs.

Look at what the default gets you. Supabase's free tier is generous on paper: 500 MB of database, fifty thousand monthly active users, community support. Then read the line underneath on the pricing page, which says free projects are paused after one week of inactivity. Think about what that means for a quarterly commission tool. It is used four times a year, which means it is asleep every single time somebody needs it. The same comparison table shows automatic backups arriving on the Pro plan at twenty five dollars a month, with daily backups retained for seven days. On free, the box holding the only copy of your team's numbers is not backed up at all.

So the rule, and it is the whole second half of the answer: build a face, not a filing cabinet.

Your deal-scoring tool reads the pipeline out of the CRM and writes the score back onto the CRM record. The score lives in the CRM, where it is backed up by a vendor you already pay, visible to people who have never opened your tool, and still there on the day your tool stops existing. Your app's own database, if it has one, holds a session and maybe a cache. Nothing that matters. If the whole thing burns down on a Tuesday you stand it back up on Wednesday and the only thing anyone lost was the convenience.

That is the difference between a tool your company benefits from and a tool your company is exposed to, and you decide which one you are building in about the tenth minute of the build, when you decide where a number gets saved.

The honest take

Three places this answer gets uncomfortable, and one where it is not really about software at all.

The face-not-filing-cabinet rule genuinely breaks when the workflow creates information that no existing system can hold. A field inspection checklist with photographs, a shop-floor QA log, a custom intake form with twenty fields that map to nothing in your CRM. There is no system of record to write back to, because you are the first person to record any of it. Fine. But then stop pretending you built a page and admit you are running a system: pay the twenty five dollars, turn the backups on, check that they restore, and write down in a findable place who owns it. The mistake is not building it. The mistake is building it and continuing to describe it as a little thing you threw together.

The free Zero Trust plan has a real price and it is not measured in dollars. That same pricing page puts standard log retention on the free plan at up to twenty four hours, with support being community forums and a Discord server. So when a prospect's security questionnaire asks who accessed the system holding customer data over the last ninety days, you have yesterday. And when something is broken at 8am on a Monday you have a forum. For a five person team running one internal dashboard that is a perfectly reasonable trade. For a company that just signed a customer with a compliance department, it is a thing to fix before the question gets asked rather than after.

There is a cliff at fifty users, too. Above that the pay-as-you-go rate on the same page is seven dollars per user per month, which for a ninety person company is somewhere around seven and a half thousand dollars a year. Still cheap against the alternative. No longer free, and worth knowing before you build the whole organization's habits on top of it.

The last one is not technical and it is the one that actually ends these stories. The tool works. People start using it. Within a quarter it is load-bearing, which means somebody's Monday genuinely does not happen without it, and it is not in a budget, not in a runbook, not in anyone's job description, and not known to anyone who would notice its absence in advance. You did not build a risk by writing bad code. You built one by being good at this quietly.

So the day the tool gets its fifth regular user, tell your manager it exists. In writing. What it touches, what it costs, what happens if it stops. Not to ask permission, you already built it. To move it from a secret to an asset, which is the only move that gets it maintained after you are the one who is gone.

What you actually skipped

Everyone frames this as beating the engineering queue, and on the code, you did. Four hours against six weeks is not close.

But the six weeks were never six weeks of typing. Most of that queue was somebody deciding who gets access and how it gets revoked, somebody deciding where the data would live and who would back it up, and somebody putting a name in a document next to the thing so that its failure had an owner. You just did the first two in an afternoon, for about forty five dollars a month, which is the genuinely new part and it is worth being pleased about.

The third one is still open, and it is the only part of the old process that was never about engineering at all.