Decide whether you sell books or lend them
A bookshop reduces stock when a copy is sold and the copy never comes back. A library or book-lending club checks a copy out and expects it back, so the same title can be available, on loan or overdue. The two models need different records, and mixing them in one quantity number produces counts nobody trusts.
Start with the model you actually run. A used bookshop often needs both per title: one quantity for new copies and graded quantities for used copies in good, fair or poor condition. A small lending library needs the member, the checkout date and the due date on every loan.
Make the ISBN the key, then describe each copy
Give each title its ISBN, title, author and format, and reject a duplicate ISBN so the same book is never catalogued twice. Track copies separately from the title: a title is the work, a copy is the physical thing on the shelf with a condition and a location.
For a first version, keep one shelf or genre label per title and one condition label per copy. Pricing rules, supplier orders and ISBN lookup services are later additions that should be tested separately — this page is a build brief, not a claim that those integrations are built into BrainHalf.
- Title: ISBN, title, author, format and genre or shelf.
- Copy: condition, acquisition date and asking price if you sell.
- Loan: member, checkout date, due date and return date for lending.
- Alerts: titles at or below a reorder count, or loans past their due date.
Start with a specific book-inventory prompt
Replace the shop type and condition grades with your own. Ask for a real database explicitly, and use made-up titles until the behavior has been checked.
Build an inventory app for a small used bookshop. Catalog titles by ISBN with title, author, format and genre, and reject a duplicate ISBN. For each title track copies by condition: new, good, fair or poor, each with its own quantity and price. Let staff record a sale by ISBN and condition, reducing only that quantity, and show a low-stock list of titles with fewer than 2 copies in any condition. Require sign-in and keep each shop account’s records private in a managed database so they survive reloads. Reject sales that exceed the available quantity. Include mobile layouts and clear loading, empty and error states. Keep sample titles clearly labeled.Open the app builder
Test the catalog with titles you know
Add a sample title with an ISBN, then try adding the same ISBN again — the app must refuse the duplicate. Give the title 2 good copies and sell both: the quantity should reach 0, a third sale should be rejected, and the title should appear on the low-stock list.
If you lend, check a copy out to a test member, confirm the title shows as on loan, then record the return and confirm availability recovers. Set a due date in the past and confirm the loan appears on an overdue list.
- Reload and confirm the title, its copies and the sale or loan records remain.
- Sign in with a separate account and verify it cannot read the first shop’s catalog.
- Test a failed save: the form should keep the entered ISBN and not report success.
- Try long titles, an ISBN with a check digit of X, and a price of zero.
- Use a phone to add a title and record a sale from start to finish.
Publish after the catalog passes
For supported managed apps, BrainHalf builds and verifies a saved version before activating the public release. Production has its own database; development test titles are not copied. Test sign-in and one disposable sale or loan on the public URL before cataloguing real stock.
Decide how to recover records before you depend on the app. Restoring source code does not restore a database, so keep an export of the catalog you cannot afford to re-enter.
Reference documentation