Choosing between off-the-shelf and custom software is settled by the record model, which is why a price table answers the wrong question. The question is whether one record in the product means one record in the business. At Kokudankokuya the same fragrance sells in several volumes, so the scent remains one product record and each volume carries its own stock and price.
Where the two definitions disagree, the gap does not evaporate. A configuration screen cannot close it: it adds fields, renames labels and switches workflows on and off, and it leaves untouched what the product treats as one record. The gap lands somewhere else instead: on a machine, on a print run, or in a second ledger somebody keeps by hand.
Every ready-made product carries its own record model
Perfume retail shows the mismatch in a line. Standard e-commerce assumes one product is one record. In the Kokudankokuya store the sellable unit is the bottle volume rather than the scent, because the same scent sells in several volumes.
A ready-made setup offers two ways out of that knot, and neither one holds. Open every volume as its own product and the catalogue fills with repeats of the same scent and the listing works against itself. Merge the volumes into one product and per-volume stock and pricing disappear; nothing in the record tells you which bottle size ran out. A settings screen will hand you a variant field, but it cannot tell you whether a variant is a sellable unit.
We drew the boundary at the volume. The scent stays one product record. Volumes hang off it as separate sellable units, each carrying its own stock figure and its own price. Adding a volume adds a unit under an existing record instead of opening a new product.
The record model shapes browsing as much as stock. Alongside the category tree we built a second axis of navigation: scent family and note. A perfume can attach to more than one note rather than one branch of the tree. A customer who does not know the brand name starts from the character of a scent and arrives at the product from there. How people find a thing belongs to the record model too.
Whose definition holds the rule
A mismatch does not always sit in the data model. Sometimes it sits in a rule, sometimes in a brand.
Buy a ready-made panel and the institution ends up wearing the software’s name on its own login screen. The Vipkurum platform needed the opposite. Here 7 institutions sign in from their own domains, each under its own branding, on one shared core. Student, guardian and payment records never cross a tenant boundary; one institution’s record is invisible to the one next door. Adding an institution means writing a tenant definition, not standing up another installation.
The second mismatch was the grading rule. Compiled into the product’s code, a criterion leaves the institution waiting for a release every time it moves. Here the institution defines the assessment type itself, which is why European and Turkish criteria sit side by side on the same exam record.
The alternative was a separate installation per institution, and it was rejected early: a separate database, a separate version and a separate upgrade schedule for each one. That arrangement looks cheap for the first customer and turns maintenance into a job of its own as institutions accumulate. The tenant boundary was drawn while the core was still being written. Drawn later, it would have meant reassigning an owner to every record already stored.
Roles come from the same place. A teacher, a guardian and an administrator each reach the same timetable record at the depth their permission allows, and timetable, class, section, exam and payment sit in one data model. A ready-made product ships a fixed set of roles; wherever an institution’s own division of labour does not fit that set, the misfit stays in somebody’s hands.
When the ready-made option is a machine
In some work the ready-made option is not software at all. It is a machine. The invoice shows one cost; the limit the machine writes into the process is the larger one.
Optical mark reading is one of those. The reader sits at a single office, so branches carry their answer sheets there and queue for results. The day it breaks, grading stops for the whole institution. The quieter cost is the sheet itself: you cannot step outside the layout the device accepts. Change that layout and the fix becomes a procurement question, a new device or a print run of device-specific forms, with nothing on the software side to answer it.
In the optical mark recognition tool the marks are read from the image of the form rather than a reader’s optics, with OpenCV doing the work on the Python side. Sheets are uploaded from an ordinary scanner. A branch scans and grades its own exam and nothing travels to a central office. When the layout changes, the adjustment happens in software.
On a construction site the ready-made option is a turnstile. Sites are temporary, so hardware installed there is installed in order to be removed. Crews also move between sites, so a record tied to one gate never held in the first place.
In the site attendance system the QR code establishes who scanned and the location establishes which site; the two arrive together in a single entry record and nobody types a site name. Entitlement is produced from matched entry and exit pairs rather than kept in a separate spreadsheet. An entry left open stays visible as an incomplete record until its exit is scanned, so a dispute is settled against the record itself. When the site closes there is nothing to uninstall; the system lives on each worker’s phone.
Anything printed is also a hardware step
A hardware step is not always a machine. In printed material, content gets sealed into its carrier: the moment paper comes off the press, the information on it freezes. If a price moves, a job title changes or a specification list is updated, the task is not a record edit but another print run. Printing behaves exactly like an optical reader or a turnstile: the process waits there and spends money there.
A showroom makes the step visible. The floor fits a limited number of cars, and a busy hour leaves few advisors free. A printed brochure covers that gap, but every price or specification update means printing it again. In the showroom kiosk application a specification update does not produce a brochure; the content travels from one codebase to the devices standing in the store. The application runs on the store’s device rather than the visitor’s phone, so there is no download, no account and no personal data left behind. The interface was built for someone seeing the screen for the first time, standing up and short of time.
The same step sits behind a butcher’s counter. A printed menu means a fresh print run on every price change; laminate the menu and you laminate the price with it. In the Çatalca Merkez Kasap QR menu the menu lives as text. A price change is an edit to a page, and the same printed QR code opens the current version without a reprint. The menu is split into sections and each section carries its own address, so codes on different tables and in the window land on different points of the same page.
A business card is the smallest version of the problem. The card is printed once while the business keeps moving: numbers change, titles change, addresses go stale. In QRVizit the distinction we are building right now is that the code is permanent while the content is not. The address behind the printed code is fixed once and the profile page behind it is edited from a panel, so a change updates a record rather than a box of cards. The product is still in development.
| Physical step removed | What replaced it | Project |
|---|---|---|
| Printed catalogue and brochure — reprinted on every price or specification update | A touch application running on the store’s own device, fed from a single codebase | KGM SsangYong showroom kiosk |
| Printed menu — a new print run on every price change | A QR menu page with separately addressed sections; a price change is a page edit and the same code opens it | Çatalca Merkez Kasap QR menu |
| Reprinting a business card whenever a detail changes | A QR code whose address is fixed once, backed by a profile page edited from a panel | QRVizit — in development |
Where printed material carries no update through the process, printing is not a hardware step. A one-off invitation, or a notice that expires on a date, behaves that way: the content is printed precisely in order to be frozen. The test is whether the information on the page keeps moving after the page comes off the press.
The second ledger somebody keeps by hand
When a product does not hold a record, the record does not disappear. A person holds it, and that is where errors get in, because the second ledger knows nothing about the first.
A teacher crops questions in an image editor and types the answer key into a separate document. One row slipping in that key turns the scoring of an entire exam wrong, and the mistake stays invisible until results go out. In the question cropping tool the key stops being a separate document and moves onto the record of the cropped question. The work was split on purpose: separating a question from the page is image-processing work, tying an answer to it is language-model work. Leave the crop boundaries to a model’s judgement and the question boundaries stop being trustworthy. When a question is needed that nobody has on file, the model writes it from existing examples together with its answer key, so the key goes onto the same record instead of being typed afterwards.
Manufacturing repeats the pattern. Before the heater selection software, Resterm held the calculation in a spreadsheet, the catalogue in a file and the quote in a third place. Once a selection and its quote line drifted apart, nobody could read back which figure produced which item, and the answer lived in somebody’s memory. We built on Resterm’s own product structure; bolting a catalogue onto a general-purpose quoting tool would have left the calculation and the quote line in separate places again.
In a dental clinic the ledger was the calendar. A general-purpose booking tool holds the hour but not the step of a treatment plan, so the plan came off the calendar, the invoice off a paper book and the month-end figure off a third sheet. In the clinic CRM the treatment plan is a record in its own right: it is set up per tooth, broken into sessions, and every appointment attaches to a specific step. Move the plan and the calendar moves with it, so no appointment is left pointing at nothing. The invoice comes off the patient record.
What these cases share is that the hand-kept ledger is invisible. Nobody calls it a system, and when a figure fails to add up at month end, nobody knows where to look.
The constraint sets the size of the answer
Everything above points toward writing something. The same portfolio argues the other way in places: sometimes the constraint says do not write, and sometimes it says write small.
The KGM SsangYong corporate site was already live. The brief was not a new site but a lighter version of the one that worked. We read the codebase first and left the working sections alone, keeping the work to the places carrying the page weight. Vehicle images moved into one naming and folder scheme, so which model uses which file is visible without reading code. Catalog reads are served from a Redis cache, so the same query no longer reaches MySQL on every page view and MySQL runs only when data changes. The technology choice followed from where maintenance would sit: we stayed inside the existing Laravel, Tailwind and jQuery set, and the cache layer was the one thing added to the stack.
The other direction is writing something small. At Çatalca Merkez Kasap the constraint was where the reader stands: at a table, on their own phone, on a weak connection inside the shop, deciding in a few seconds. The menu was built as a single page with Vue 3, so moving between sections after the first load does not open a new page request. There is no ordering, payment or stock layer, and no dependency delaying the first paint. It is the smallest piece of web development in our portfolio.
Kokudankokuya reads the same way from the other end. The size of that catalogue never called for a separate search or cache layer; the store runs on Laravel and MySQL. What becomes specific is the record model, and the infrastructure underneath does not have to follow.
Whoever will keep the result running decides the stack for you.
The questions that actually decide
The decision comes down to five questions.
Is the unit you sell or track the same as the product’s unit of record? In perfume it is the bottle volume; in a clinic, the treatment plan. Neither fits a standard product or appointment record.
Does your rule live in the product’s code or in your own definition? A grading criterion compiled into software means waiting for a release every time the criterion moves.
Which step of the process sits on a device, on a sheet of paper or on a print run? Wherever that step sits, the process waits there: at the optical reader, at the turnstile, at the reprint of the brochure.
Who types the same information a second time? The error enters on that second pass, in an answer key as readily as in a quote line.
Who will maintain what you build? The answer sets the stack.
If you can answer every one of them with “they match, nobody keeps it by hand, no step waits on paper”, the ready-made product is the right answer and there is nothing to write.
Where they do not match, what closes the gap is not configuration but a redefinition of the record itself. Working through these questions against a real process is the first thing we put on the table on the software consulting side.
