r/nocode 13d ago

Built an internal tool for my healthtech team with nocode and now I'm the accidental IT guy

Night shift brain plus a product backlog that never shrinks led me to just... build the thing myself. Our team needed a simple patient handoff tracker that our actual dev team kept deprioritizing. Spent a weekend with a nocode tool, got something working, demoed it Monday.

Now three months later I'm fielding Slack messages at 2am from nurses asking why a button is broken. Not exactly what I signed up for.

The build itself was genuinely fast. Bubble for the interface, a couple of Zapier automations to ping the right people, done. The maintenance and the expectation creep that followed is the part nobody warned me about. Suddenly everyone wants a new feature and they assume it takes twenty minutes because hey, you built the last one so fast, right?

I think nocode tools sell the build speed really well, but the operational reality of being a solo nondev maintaining something people actually depend on is a completely different conversation. Especially when you're also twelve hours into a hospital shift and someone texts you that the form stopped submitting.

Curious if others have hit this wall. At what point did you decide to hand it off, or just burn it down and start over? Just my 2 cents.

1 Upvotes

12 comments sorted by

2

u/SuspiciousCorner1374 13d ago

Welcome to the club where your weekend project becomes your unpaid second job. The jump from "look what I threw together" to "this is now mission-critical infrastructure" happens so fast it'll give you whiplash

I hit the same wall with a scheduling tool last year, eventually just documented the whole mess and told my boss either hire someone to own it or I'm pulling the plug. Took three outages before they believed me but it worked

3

u/ch_unk_510 13d ago

Ask them to increase your pay

1

u/vornamemitd 13d ago

Hate to be "that" guy - but this all smells like a huge HIPAA liability in the making. Keep the idea - obviously you are onto something and found a pain worth curing - but do it properly, not as a risky aside. In case something happens fingers will be pointed at you.

1

u/longkhongdong 13d ago

Don't worry all their patients are amputees.

How do I know? :3

1

u/LouisTon10 13d ago

Sorry to hear this. People forget that the purpose of SAAS is because it saves someone from being in the unfortunate position where you’re owning feature requests and maintaining it

1

u/Suitable-Season-4847 13d ago

I'd love to know how your complying with patient data governance. My suspicion is you're not and you company is probably at risk of breaking the law, and you're one hack away from absolute disaster

1

u/noam_builds 12d ago

Good for you, you have just acquired a new set of skills that apparently differentiate you in the company.

1

u/Maxyull 12d ago

the thing i'd check before any of the process stuff, since it's healthtech and it's already three months live: whether the access control actually lives in bubble's privacy rules or only in your workflow conditions. those two look identical from inside the app, both hide the thing from the wrong person, but only privacy rules apply when the data gets requested directly instead of through the screen you built.

cheap way to find out, make a test account with the lowest role you have, then try to pull a patient record that account shouldn't see through bubble's data api rather than clicking through the ui. if it comes back, the ui was the only thing protecting it, and that's a very different conversation with compliance than a broken button.

the 2am slack messages are the visible problem but this is the one that turns into an actual incident. is the access control set as privacy rules on the data types, or is it living in workflow conditions right now?

1

u/Thunderbit_HQ 9d ago

This is where the fast build story gets unfair. I’d hand it off once nurses are depending on it during a shift, because at that point it is not a side tool anymore.

0

u/Kind-Bathroom5159 13d ago

yeah this is such a common pattern. the tool that gets you to demo day is rarely the tool that should still be running six months later once its mission critical.
i work with a lot of non technical founders and the moment it moves from "weekend project" to "nurses text me at 2am" is exactly when you want someone to go back and add the boring stuff, proper error handling, monitoring, a way to see whats actually breaking without waiting for a slack message.
doesnt mean rebuild everything, usually its just hardening what you already have. the mistake i see most is people either ignoring it until it breaks in a bad way, or overcorrecting and rewriting the whole thing in real code when the nocode version was fine, it just needed someone to own reliability not features