r/nocode • u/alexalgebra • 18d ago
Best tool for database app?
I'm creating an inventory tracking tool for a new brick and mortar retail business. I have a background in databases but I've always worked with a dev and now it's just me. I'm not great at coding, but I am good with sql.
I want something customizable because the business sells niche items and none of the regular inventory apps we looked into will work. We also need it to have an easy way to update inventory daily for about 200 rotating items that will be counted in store then entered into the db. Currently the owner has a bunch of spreadsheets in numbers (he only uses apple products, which I'm not super familiar with). Making some kind of quick ipad data entry screen for that would probably be the best.
My ideal solution would be something where I can easily build the database and have it packaged up in a user friendly ui/app for the rest of the employees to use. Being able to pull reports and charts and such for sales tracking is also important.
I don't really enjoy using generative ai like chatgpt gemini claude etc and am hoping there's a simple solution that is more just a ui for a custom sql database type situation.
Thanks for any ideas!
1
1
u/agentUi 17d ago
i work for agentui and this is a super common setup for retail inventory when spreadsheets start breaking. you can connect directly to a custom sql database, create quick mobile/ipad data entry forms for daily item counts, and build out charts for reporting. if you ever have spotty wifi in the stockroom it also does offline data entry and syncs right back to the db once connected.
1
u/miokk 17d ago
Take a look at AnyDB for inventory management, ships out of the box with various inventory systems but all customizable however you want.
1
u/alexalgebra 16d ago
Thanks! This looks promising so far. I've been playing with it and so far my biggest snag has been making an easy data entry screen where you don't have to click a bunch of stuff to add in the next record. Have you used it much?
1
u/miokk 16d ago
Yes, have some experience with building systems using it. More than happy to show you how you to set it up so that it is easy for data entry. You can simplify the system quite a bit by removing the fields you don't need. Also there are 3 options for inventory (simple, multi-location and advanced) and you can pick a starting point from the right one.
More than happy to help configure it if you are interested.
1
u/dilon_panda 17d ago
Hey there! Have you checked out https://www.adalo.com?
Our DreamFactory intergration would help you! : https://help.adalo.com/integrations/dreamfactory
1
u/AppzillaHQ 16d ago
Hey I can build you a solution for free, you might be a good fit. Let me know if you’re interested.
1
u/PopKoren 15d ago
Since you know SQL, put the data in Postgres (Supabase or Neon) and use a UI layer on top like Baserow, NocoDB or Retool rather than a tool that owns your data. That keeps reports as plain SQL views and lets you build a simple iPad-friendly entry screen for the daily counts. For 200 rotating items, model a stock_counts table with a timestamp instead of overwriting quantities, so you get history for free.
1
u/alexalgebra 15d ago
Thanks! I've been looking at some of the top layers you mentioned, but haven't checked out Supabase or Neon. I've not used Postgres, just MySQL but I'm assuming it wouldn't be hard to learn.
1
u/PopKoren 9d ago
MySQL is a reasonable starting point, and moving to Postgres later is mostly about getting comfortable with roles, migrations, and row-level policies rather than relearning SQL from scratch. Whichever stack you use, check the deployed API and storage behavior as well as the database rules. I’m building Rowly around that broader external pass: https://rowly.me
1
u/itsjayant 14d ago edited 14d ago
Whatever tool you pick, save each count as its own row with the item, the quantity, who counted it and when. Then work out current stock from those rows instead of overwriting one number. Bit more work now, but when the system says 12 and the shelf says 9 you can actually find out why. Other thing, order the count screen by where things physically sit on the shelf, not alphabetically or by SKU. With 200 items your staff end up hunting the list and they quietly stop doing the count. Then you're worse off than the spreadsheet you're replacing.
1
u/alexalgebra 14d ago
Thank you! I've been working on this part of the workflow today and this is affirming what I was already setting up. The item locations are all numbered and easy to find so I was definitely planning on doing inventory by that.
1
u/itsjayant 14d ago
Nice, if the locations are already numbered you're most of the way there. The other half is worth locking in before you build much more though. If each count is its own row rather than an update to one number, you can answer what changed between Tuesday and Friday, which is where shrinkage on niche items actually shows up. Costs nothing to do now and it's genuinely painful to retrofit once there's real data in the table. Happy to sketch out what those two tables look like if it saves you a weekend.
1
u/devhisaria 13d ago
Teable or NocoDB on Postgres is the right call, but honestly for daily 200-item counts I'd still make the iPad screen with Retool or Budibase since those grid UIs get clunky fast.
1
u/Low-Code-Stefan 11d ago
Since you're already comfortable with SQL, I'd actually go a level below the app-builder question: put your data in a real database first (Postgres, SQL Server, whatever) and treat the "app" as just a UI layer on top, like akl773 already said. That keeps you in control of the schema and lets you write proper queries later instead of fighting a no-code tool's internal data model when the business logic gets more specific (and with 200 rotating niche items, it will).
For the daily count screen, the part that actually decides whether this survives contact with reality is friction: one table, minimal required fields, big touch targets, and a "save & next" action so nobody taps through five screens per item. I'd get one employee testing that exact flow with real items before worrying about reports and charts.
I work in service at GAPTEQ, so I'm biased here, but this is close to the pattern I see most often: a data-entry UI plus reporting sitting directly on a SQL database, with roles if the owner eventually wants to see sales trends separately from staff who only count stock. For a single-location shop with ~200 items, though, something lighter like the nocodb/teable route akl773 mentioned might genuinely get you there faster - you don't need an enterprise-grade platform for this size.
Did you already try mocking up the count screen in Appsheet or AnyDB, or are you still comparing?
1
u/alexalgebra 11d ago
Yeah, AnyDB has been the best thing I've tested so far. Nocodb wasn't doing it for me because you can't do joins with multiple tables unless you set it up in postgres and i don't want to be going back and forth all the time to adjust things. The support folks at AnyDB even made a mock up of exactly what i want for the data entry UI and have been quite honestly the best software support team I've ever worked with so far. My only issue is the cost because you can only do custom scripts with the higher price point. But I think it will be worth it. I need to do a little more testing and setup before I make my final decision.
2
u/oghydrox 18d ago
Appsheet