The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
A classifieds platform for the people who buy and sell plastic processing machinery. The catalog is locked to one machine family and the category tree follows the distinctions inside it; new and used stock share a single list, with condition acting as a filter.
Visit the site →Buyers and sellers of plastic processing machinery have long found each other by phone, through an acquaintance, or under the industrial heading of a general classifieds site. Those routes all fail in the same way: under a heading that wide, the distinctions that actually matter about a machine stop being visible. Plastik ve Makina was built for that gap. One limit is worth stating plainly. The platform brokers nothing, and negotiation and payment stay between the two parties. The catalog was our part of the job.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
The whole tree follows the distinctions inside one machine family, so what sits as a sub-heading on a general site becomes the main axis here.
Both conditions share a single list; a buyer switches condition on and compares the two options inside one search.
Laravel builds the list on the server and Inertia hands it to the browser, so changing a filter refreshes results without a full page load.
MySQL stores the listings, Redis carries the cache layer, and Tailwind shapes the browse and detail views buyers actually read.
| Challenge | Result |
|---|---|
| Buyers and sellers found each other by phone or through someone they knew | Buyer and seller meet in one place rather than through a chain of acquaintances |
| On a general classifieds site these machines sit under one industrial heading | What is a sub-heading on a general site is the main axis of the tree here |
| A seller could not reach the buyer already looking for that exact machine | A seller lands in front of the buyer already looking for that exact machine |
| Split across separate lists, new and used stock cannot be compared | New and used stock appears side by side in one search |
| A full page reload on every filter change breaks the flow of a search | Changing a filter refreshes the list without reloading the page |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
