The operating problem
Leobot Electronics began as a practical test of a generic ecommerce platform using surplus components from an import. It grew into a live electronics business with more than 1,500 products, thousands of orders and years of catalogue, stock, fulfilment and customer history. That operating exposure changed how INESSOFT thinks about commerce software: the public site is only the visible edge of a much larger internal system.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 05 Jul 2026 · Last reviewed 05 Jul 2026Catalogue design becomes a business capability
A large specialist catalogue contains more than names and prices. Products need categories, specifications, compatibility, search terms, images, stock status, supplier relationships and content that helps buyers choose correctly. Weak structure shifts the cost into support questions and manual product discovery.
- Model stable product identity separately from changing commercial fields.
- Design categories and attributes around buyer search behaviour.
- Create admin tools that make data quality visible at scale.
Stock truth is operational, not cosmetic
Displaying availability creates a promise. The platform must reconcile receipts, sales, reservations, adjustments and physical counts. Even when stock is physically held on premises, delayed or inconsistent movements can undermine confidence and create fulfilment work.
- Define when stock becomes reserved and released.
- Record movement reasons rather than editing quantities invisibly.
- Provide exception views for negative, stale or suspicious availability.
Search quality directly affects revenue and support load
Electronics buyers often search by part number, abbreviation, technical term or application. Search must tolerate naming variation while still producing precise results. Better discovery reduces abandoned sessions and the number of customers who need staff to find routine products.
- Index codes, aliases, specifications and category context.
- Learn from zero-result and refined searches.
- Keep filters useful rather than exposing every database field.
The order lifecycle continues after payment
Orders move through verification, picking, packing, collection or shipping, communication and exception handling. A storefront that stops at payment forces the team back into email and manual notes. Internal status, ownership and customer-facing updates should describe the same underlying state.
- Model fulfilment states and allowed transitions explicitly.
- Keep customer communication linked to the order record.
- Expose delayed or blocked orders to staff before customers must ask.
Internal tools compound over years
Supplier imports, sales-growth workflows, internal messaging, kit builders, pricing helpers and reporting tools may look secondary compared with the public shop. In practice they reduce repeated administration and allow a small team to manage more complexity. Operating platforms reveal where small internal systems create disproportionate value.
- Prioritise tools around repeated high-volume decisions.
- Integrate helpers with core records instead of creating more spreadsheets.
- Measure time removed from catalogue, purchasing and fulfilment work.
SEO and URL continuity are product concerns
A long-running catalogue accumulates search equity, external links and customer habits. Replatforming or reorganising routes can destroy discovery even when the new site is technically better. Canonical URLs, redirects, metadata and sitemap behaviour need the same care as database migration.
- Inventory existing indexed routes before structural changes.
- Preserve or redirect valuable product and category URLs.
- Avoid replacing useful content with visually cleaner but thinner pages.
Live systems reward incremental modernisation
A working commerce platform cannot be treated like a greenfield demo. Changes affect orders, users, stock and search traffic. The safer approach is to stabilise fragile areas, extract valuable modules and improve deployment and diagnostics while preserving validated business behaviour.
- Separate urgent operational risk from aesthetic debt.
- Test changes against real catalogue and order edge cases.
- Keep rollback and data reconciliation practical.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
The storefront works but staff rely on many manual back-office steps.
The largest value may be internal operational software.
Map catalogue, purchasing, fulfilment and support workflows before redesigning the front end.
Stock shown online is frequently corrected after orders.
Movement and reservation rules are weak.
Build a controlled stock ledger and exception review.
Users struggle to find products despite a large catalogue.
Search and information architecture are revenue constraints.
Improve aliases, attributes, filters and zero-result analysis.
A replatform is proposed mainly for visual modernity.
Migration risk may outweigh value.
Audit SEO, routes, integrations and operational behaviour before replacement.
Evidence that the current approach is becoming risky.
- Product records cannot be maintained consistently by normal admin users.
- Stock quantity is edited directly without movement history.
- Order status in customer communication differs from internal reality.
- Search ignores part codes, aliases or technical attributes.
- A redesign changes URLs without a migration and redirect plan.
What to clarify before commissioning work.
- Map product, category, attribute and supplier ownership.
- Define stock movements, reservations and reconciliation.
- Analyse product search terms and zero-result queries.
- Model the complete order and fulfilment lifecycle.
- Identify repeated internal admin tasks suitable for focused tools.
- Protect indexed routes and metadata during modernisation.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
When is custom ecommerce justified?
When catalogue, pricing, stock or fulfilment complexity creates persistent manual work that standard platforms cannot support cleanly without fragile extensions.
Should a live custom platform be replaced because it uses older technology?
Not automatically. Assess security, supportability, change cost, SEO and operational risk. Incremental modernisation may produce better value.
What is the most important ecommerce database record?
There is no single answer, but stable product identity, stock movement and order state are foundational because many other functions depend on them.
How do internal tools affect customer experience?
Better catalogue maintenance, stock accuracy, fulfilment visibility and staff workflows reduce errors and delays that customers experience directly.