Learning notes from Booknix and IQ-POS · Muhammad Faisal (DEV47) · Week ending October 16, 2026
Building software that people rely on, such as booking a ticket or running a shop, is mostly about stopping small mistakes from becoming big ones. This week I worked on two products and learned seven lessons that apply well beyond programming. You do not need a technical background to follow them.
The two products behind these lessons
Booknix is a booking app for cinema, events, parties, seminars, bus travel and restaurant dinners. It has separate screens for customers, for the organizations that run the services, and for bus drivers.
IQ-POS is software for shopkeepers. It handles billing at the counter, stock, printed and digital receipts, reminders sent over WhatsApp, and searching for a product by photo. A Windows desktop version is also under way.
Who this is for
This post is for business owners, students and curious readers who use apps like these and want to understand what goes on behind them. Every technical term is explained in plain words, and a short glossary sits near the end.
The seven lessons at a glance
#
| Lesson | In everyday terms | |
| 1 | Keep a record of how things were | A printed receipt should never change after the fact |
| 2 | Save linked information together | Money and goods change hands at once, or not at all |
| 3 | One party responsible for each decision | The restaurant confirms the table; the guest accepts it |
| 4 | Find the real cause | A car that will not start may be out of fuel, not have a flat battery |
| 5 | Check where two parts meet | Two correct forms can still disagree about what a box means |
| 6 | Read before you run | Do not plug in a USB stick you found in a car park |
| 7 | Say what is proven | A bridge that is built is not yet a bridge that is load-tested |
1. Keep a record of how things were
What happened. IQ-POS receipts were drawn using the shop’s current settings. If a shopkeeper later changed the receipt design, old receipts would quietly change too.
What we did. When a sale is completed, the system now saves a snapshot: the shop name, logo, layout and a verification QR code. Reprinting an old receipt uses that snapshot, not today’s settings. The QR code lets anyone confirm a receipt is genuine, and it reveals only the shop, bill number, status and total, never the customer’s details.
Why it works. Think of a photograph versus a window. A window shows how things look now, while a photograph shows how they looked at the moment it was taken. Receipts, invoices and tickets must be photographs.
Try it yourself. Ask: if this detail changes tomorrow, should yesterday’s document change? If not, copy the detail into the document when you create it.
2. Save linked information together
What happened. IQ-POS lets a customer search for a product by taking a photo. To make that work, each product photo is turned into a list of 512 numbers that describes how it looks, like a digital fingerprint. The system compares the customer’s photo against those fingerprints and shows the closest matches.
What we did. The photo and its fingerprint are saved in a single all-or-nothing step, which databases call a transaction. If anything fails halfway, neither is saved, so a product can never end up with a photo and a fingerprint that describe different pictures.
Why it works. Compare it to paying in a shop: you hand over money and receive the goods in one exchange. Nobody wants a payment taken without the goods, or goods handed over without payment.
Try it yourself. When two pieces of information must always agree, save them together. Leave delayed background work for tasks where being late is harmless.
3. One party responsible for each decision
What happened. In Booknix, a bus driver receives an assignment, accepts or rejects it, starts the journey, and marks each passenger as checked in, boarded or absent. The organization separately decides whether the assignment is active. Putting all of that into one status would mix up who decided what.
What we did. Each decision has its own field with a single owner: the organization’s activation, the driver’s response, the journey’s progress and each passenger’s attendance. The driver is identified by their login, never by a number sent from their phone, so one driver cannot act as another. The app also hides a passenger’s emergency contact until the driver taps to reveal it.
Why it works. A restaurant confirms that a table is free, and the guest decides whether to accept it. If both used one shared note, a later reader could not tell who changed what. We also lock each assignment while it is being updated, so two quick taps, or two phones, cannot both succeed at the same moment. This kind of clash is called a race condition.
Try it yourself. For every decision in a process, write down who is allowed to make it and why. Different people with different reasons should get different records.
4. Find the real cause
A problem often appears far from where it began, just as a car that will not start might have an empty tank rather than a dead battery. Five problems this week looked unrelated until each was traced back to its true cause. What it looked like
| What was really wrong | The fix | |
| The database refused to add the search feature | The feature had never been installed on the database computer | Install the version that matches the database |
| An error said a data type did not exist, though it was installed | The tool was looking in the wrong place (the wrong schema, which is like a folder) | Tell every step exactly where to look |
| A browser download reached 100% but nothing worked | The file was downloaded but only partly unpacked | Unpack the complete file |
| The WhatsApp connection would not start | The add-on was packaged in an older style that the app misread | Add a small translator that checks the add-on loads correctly |
| The desktop app opened to a blank window | Three separate faults: a file format, a wrong file location and a security setting | Fix each, add a test, and show a message instead of a blank screen |
Why it works. Repeating the same step rarely helps when the real problem sits elsewhere. Naming where the fault lives, such as the database, a download, a package or the app itself, tells you where to look.
Try it yourself. Before fixing anything, ask which part is actually failing, and check that part directly.
5. Check where two parts meet
What happened. Searching by photo failed with an error even though the photo was fine. One part of the app sent two pieces of information: the photo and a shop number. The part receiving it treated the second item as how many results to return.
What we did. The shared piece now sends only the photo, and each page adds the extra detail it needs. A test now checks this hand-over so it cannot quietly break again.
Why it works. Picture two people passing a form. One writes a shop number in the second box, and the other reads that box as quantity. Each person is correct on their own, but the form fails. Here the shop number arrived empty, was read as zero results, and the system correctly refused it.
Try it yourself. Most surprises happen where two parts meet. Test those hand-overs, not only the parts themselves.
6. Read before you run
What happened. A login page looked plain and unstyled, so I investigated. One cause was a broken setup command. The other was alarming: a file disguised as an ordinary part of the project, in two separate code folders, was deliberately scrambled so it was hard to read. Its job was to contact outside servers and start a hidden background program.
What we did. We acted in a careful order. First we removed the file and avoided running the project’s commands. Then we repaired the broken command, and finally we checked the results by reading rather than running, because running the build could have opened files holding secrets.
What removal does not fix. If the file ever ran, the computer needs a security scan, every password and key it could reach must be changed, and the bad change must be removed from shared copies of the project so nobody restores it.
Why it works. Plugging in a USB stick found in a car park is risky for the same reason. Unknown code can do anything its author intended.
Try it yourself. Read unfamiliar files and commands before running them. If you find something deliberately scrambled, treat it as a security incident, not a tidy-up job.
7. Say what is proven
A bridge that has been built is not the same as a bridge that has been load-tested. Software works the same way, and several parts of this week’s work were labelled honestly rather than called finished.
- Profit reports show how much of the cost data is complete. Older stock has no purchase records, so its sales are listed as unmatched instead of being counted as pure profit.
- The desktop login is marked conditionally complete. Real tests with live accounts, such as expired sessions and one shop trying to reach another’s data, are still outstanding.
- Push notifications return a receipt showing the message was queued, not that it reached the phone. Checking real delivery is a separate step.
- Blurry product photos were caused by old images being shrunk to 40 by 40 pixels. Software cannot restore detail that was thrown away, so the original photos must be uploaded again. New uploads now keep up to 1200 pixels.
Try it yourself. Keep two lists: what you have built and what you have checked. A report that admits its limits earns more trust than one that only looks complete.
What this means for people using the apps
- Receipts stay accurate and can be checked with a QR code.
- Product photos and their search data stay matched.
- Drivers, organizations and customers each control only their own part of a booking.
- Customers agree to the privacy policy when they register, and a deleted account can be recovered by signing in within 30 days.
- Results shown on dashboards state how complete they are.
A short glossary
Term
| Plain meaning | |
| Database | The organized store where an app keeps its information |
| Transaction | A group of saves that either all happen or none do |
| Snapshot | A saved copy of how something looked at a moment in time |
| Race condition | Two actions at the same instant that clash with each other |
| Embedding | A list of numbers that describes how an image looks, used for matching |
| FIFO | First in, first out: the oldest stock is counted as sold first |
| Obfuscated code | Code deliberately scrambled so people cannot easily read it |
| Credential rotation | Changing passwords and keys so stolen ones stop working |
A checklist you can reuse
- If this detail changes tomorrow, should yesterday’s record change?
- Must these two pieces of information always agree? Save them together.
- Who is responsible for this decision?
- Which part is really failing?
- What does each side of this hand-over expect?
- Have I read everything I am about to run?
- What have I built that is not yet checked?
What comes next
Next week’s work is removing the harmful file from shared copies of the project and changing credentials, adding a missing safety check, applying pending database updates, and testing the driver, notification and map features on real phones.