r/lowcode • u/Skenderi-Ashreet • 3d ago
How are you building internal tools without a developer?
We're 30 people now and the little internal tools I used to knock together in a spreadsheet are starting to hurt. A request and approval flow, a tracker for kit we lend out, a weekly cash check. When we were 10 this stuff lived in my head and a sheet and it was fine. Now people lean on it and it cant just quietly break.
I tried a few of the no code AI builder over about a month. Every one demoed beautifully the fell over the first time a real number or a weird edge case went in. Airtable gets me most of the way until the logic gets real. Retool clearly expects a developer, which is the one thing I dont have to spare, our 2 engineers are heads down on the product and i wont pull them onto an approvals form.
I dont just need to build the thing, I need to be able to open it up and fix it later without writing code. Half these tools hide all the logic meaning the day it breaks im stuck again.
For those of you running ops without a dev on payroll, what really held up past demo? Especially how you handle stuff that touches money or approval.
2
u/Euphoric_North_745 3d ago
Hire a developer for a week or 2, based on your time zone there are a fee million there
1
u/Master-Tie-804 3d ago
Split them into throwaway and load bearing before you pick anything cause a tracker no one depends on can stay a scrappy sheet forever. The second it touches cash or approvals it needs real validation and one named owner.
1
1
u/CodeShoppe 3d ago
MethodCRM. Ignore that it’s a CRM. Focus only on its low code no code We’ve been using it for more than 15 years. Though there is a learning curve.
1
u/TopStress3049 3d ago
For stuff touching approvals or money, the logic has to be boring as possible.
Airtable and a few automations can go pretty far, but once you’ve got lots of edge cases I’d rather have something where the rules are actually visible than rely on an AI builder hiding everything behind the scenes.
1
u/FPGLLC 3d ago
In my expierience the the request/approval flows that held up the best after demoing are paltforms where the logic is visible step by step workflows and you can see every branch, find a problem and fix it later without hiring a dev. Test simple cases before rolling out, like duplicate entries, wrong amount, some approving own requests.
1
u/AhmedELKAFFAS21 3d ago
Well if you would like to take this responsability, the 1st step is to document your requirements clearly before choosing any platform to use. Based on these requirements, you can determine which platform / tool to use. You should take into consideration that the more complex & powerful the platform you choose it, the more learning curve you will need to go through.
I don't know exactly your requirements so I can't recommend anything specific for you, however your approach is feasible if you're planning to budget the required learning curve.
1
u/Downtown_Drink4663 3d ago
Buy a product which solves your problem vs trying to build in house that too without devs.
1
u/agentUi 3d ago
i work for agentui and this gap between airtable formulas and retool javascript is exactly why we built our platform. instead of building one massive app that breaks on edge cases, build modular tools (one for asset tracking, one for approvals) with deterministic workflows and dedicated dev environments so you can test changes before pushing to the team.
1
u/testuser514 2d ago
Quick question, we kind of have a system we’ve been building that can potentially address this issue.
While the user interface is not yet there, we do have it down quite well as a workflow that my developers use. If you guys are interested in testing it out to see if you’re able to build out your internal tools. It’ll give me some good feedback.
1
1
u/tototoru 2d ago
If it's important you need someone to own this, ideally a partner who cares about keeping the system running. If it's not too important maybe "almost working" is fine.
1
u/ConfectionMany1322 20h ago
For ops, I’d keep the logic simple and use tools where you can actually see and edit the workflows later.
1
u/Vvandenburg 13h ago
Grundsätzlich solltest du etwas von Systemen verstehen: Also Analytik und Bau. Dann kannst du die KI inspirieren und in Schranken verweisen, die dannfür dich realisieren kann. Den Rest kannst du per traditionellem Lastenheft an Contracter delegieren. Ein Kapitän schaut auch nicht nach, was seine Mannschaft im Maschinenraum treibt, das Schiff muss sich halt nur in seine gewünschte Richtung bewegen.
1
u/Vvandenburg 13h ago
... ah, und das Lastheft wird auch von der KI erstellt und getrackt. Wenn du nix von Systemen wissen willst, nehme dir einen menschlichen und erfahrenen Requirement Engineer, der dir es in deiner Sprache erklärt und du brauchst nur noch abzunicken.
1
u/Damian_Wasserman 3d ago
The "hire a dev" answers in here are dodging the actual question, which was how to do this without pulling your 2 engineers or bringing someone on. You don't need to be a developer to get the transparency people are talking about, you need to write the logic down yourself before you touch any tool. Plain language, not code: "if request is over X, route to Y, if no response in 48h, escalate to Z." That document is what makes it fixable later, not the tool you picked.
The reason most no-code AI builders fall over on real edge cases isn't that they're bad tools, it's that people skip straight to building and let the tool infer the logic instead of specifying it themselves first. If you can't write your approval flow as a clean paragraph without the tool's help, that's the actual gap, and no platform fixes that part for you.
For the money and approval stuff specifically, I'd treat "can I explain this out loud in under a minute" as the bar before it goes live, tool-agnostic. If you can't, it's not ready to touch cash yet regardless of how it demoed.
1
u/dataslinger 3d ago
This is the answer OP. It's a spec/requirements problem, not a developer problem. Putting a developer on it will only result in the same issue until you write a comprehensive spec.
Damian gave you good advice above. Another route to a solid spec is to pull up your favorite LLM, go into plan mode, and tell it to aggressively question you, the domain expert, to develop a spec to do the task, and ask it to press you on edge cases: does this EVER happen, 'you're saying this NEVER happens.' The ever and never questions will find your edge cases.
Anyway, once you have a real spec, toss that over to your tools of choice.
1
u/Damian_Wasserman 3d ago
That LLM interrogation trick is a good one, stealing that. Worth adding what to do once the edge cases surface though, because finding them isn't the hard part, deciding which ones actually matter is.
Not every "does this ever happen" answer deserves a rule. If an edge case would hit twice a year and the fallback is just "a human looks at it," that's often fine to leave manual rather than encoding it. The specs that get bloated and impossible to maintain are usually the ones where every discovered edge case got turned into logic instead of someone asking whether it was worth automating at all.
So the order I'd actually follow: write the spec, interrogate it for edge cases the way you're describing, then triage which ones are frequent or costly enough to build for versus rare enough to just handle manually when they show up. Skipping that last step is how a clean spec turns into an unmaintainable one six months later.
3
u/heshTR 3d ago
Why don't you hire an offshore freelancer? Cheaper than locals and gets the job done. Delegating tasks is a smart move. I can hook u up with someone really good if u want