The problem is specific
An operator knows which hole cannot be reached, which edge fouls, what movement is awkward and what workaround is being used.
Manufacturing memory for engineered products
Stop carrying the same manufacturing problem into the next design revision.
Sclptr captures a problem where it happens, has it checked by a person, links it to the exact design feature and revision, attaches what it actually costs, and brings that evidence back when an engineer changes the product.
Built for manufacturers where useful shop-floor knowledge still gets lost between production and design.
From shop floor to design revision
Nothing below is built yet. This is the design, in the order development follows from founder-funded Version 1.
01
Capture
Record the issue at the bench while the detail is still clear.
02
Check
A supervisor validates the record before it becomes permanent.
03
Link
Attach it to the affected part, feature, operation and revision.
04
Cost it
Attach what the problem costs a year, what the change would cost, the expected saving and the payback.
05
Use at redesign
Show that history, with the numbers, when the engineer prepares the next revision.
06
Replay the revision
Check the proposed revision against that history before production, to show whether a known problem looks resolved or still at risk.
Steps 01 to 05 are Version 1, self-funded and built first. Step 06 is the destination the record set is designed to reach, and the reason the history is worth keeping.
The problem
Manufacturing problems get reported. The useful detail often does not survive.
The person building a product sees things that are difficult to capture in a drawing: poor tool access, awkward assembly, interference, fit problems and workarounds. By the time that information reaches the design team, it is often reduced to a short note, a meeting comment or a defect code.
The context is reduced
The issue may become a line in a spreadsheet, a generic defect description or a comment in a meeting. The exact feature and reason are easy to lose.
The engineer sees an incomplete history
The drawing is available, but the experience of the people who built the previous version may not be. The same problem can therefore return.
Example
On the line: “I cannot get the driver square to this hole.” In the record: “bracket access issue.” Months later, the engineer may know that the bracket caused trouble without knowing which hole, why access was poor, how often it happened or whether a previous change solved it.
How Sclptr works
Keep the manufacturing evidence with the design.
Sclptr is designed to make reporting quick for the operator, controlled for the supervisor and useful for the engineer. Steps 01 to 06 are Version 1, self-funded and built first. The last two are what the record set is designed to reach.
Nothing below is built yet. This is the design, in the order development follows from founder-funded Version 1.
Scan the job
A code identifies the station, part, operation and drawing revision.
Record the issue
A short voice note captures what happened. A photo can be added when it helps explain the problem.
Validate it
A supervisor checks the issue, confirms the category and links it to the affected design feature.
Cost the problem
Using cost figures the customer enters at setup, the record carries what the issue costs a year, the cost of changing it, the expected saving and the payback. That is what turns a report into a decision.
Show it at revision
When the product is revised, the relevant manufacturing history is available alongside the design decision.
Return the decision
The outcome goes back to the person who raised the issue, so reporting has a visible result.
Capture it in depth
Planned for Year 2. On assemblies already known to cause trouble, an experienced operator runs a booked, announced session, narrating the job while a depth sensor records how the part is actually reached, held and fitted. Depth only, with the colour stream disabled and never stored.
Replay the revision
The research direction, not a staged deliverable. Compare the earlier evidence against the revised geometry to show whether the original issue looks resolved, remains at risk, or needs review before production.
The manufacturing record
Each validated issue stays tied to the product context that gives it meaning.
Sclptr does not rely on a long free-text description. The useful engineering context is stored in a consistent structure so the record can be found again when it matters.
A validated record can include
- Part
- The component being built
- Feature
- The hole, face, edge or design feature involved
- Operation
- The assembly or manufacturing step
- Revision
- The drawing or design version in use
- Issue
- What happened and why it mattered
- Recurrence
- How often this feature has caused this kind of problem
- Cost and payback
- Money lost a year, cost of the change, expected saving and payback time
- Action and outcome
- What was changed and whether it worked
Why this matters
A note saying “bracket access issue” may be useful today and nearly useless a year later. A validated record linked to the affected feature and revision can still be useful when that feature is opened for redesign.
Over time, each manufacturer builds its own history of what was difficult to make, what was changed and what happened afterwards. Customer data remains separate between manufacturers.
Why it is hard to copy
The software itself could be rebuilt by a capable competitor. The history could not. It belongs to one factory's parts, processes and people. It cannot be bought, and it cannot be added in afterwards, because it only exists if someone recorded it at the bench while the work was happening. That is why the record becomes more useful, and harder to replace, the longer a manufacturer uses it. It is also what revision replay depends on. A competitor could ship the same capture app tomorrow and still not replay a revision, because replay reads a history it does not have.
Why it matters
Give the next design revision better manufacturing context.
The aim is not to create another source of factory data. It is to make existing manufacturing experience usable when engineering decisions are made.
Reduce repeated problems
Keep the original manufacturing issue attached to the feature that caused it, so the next revision starts with what has already been learned.
Prioritise by impact
See recurrence and cost alongside the issue, helping teams focus on the problems that matter most.
Retain practical knowledge
Keep useful experience inside the company when people change roles, move teams or leave.
Connect production and design
Give both teams a shared history of the issue, the engineering response and the result.
Where Sclptr fits
Sclptr sits between shop-floor reporting and design revision.
Manufacturers already use quality systems, work instructions, connected-worker tools and design-review software. Sclptr focuses on the link those systems tend to lose: a verified manufacturing issue held at feature level, carrying what it costs, and available when that feature is changed. Attaching frequency, cost and payback is what turns a defect log into a decision. That same evidence is what revision replay is built on. A system that collects only design-office comments or formal non-conformances does not hold the shop-floor history to replay.
Record formal non-conformances, inspection results and corrective actions.
Support shop-floor work and capture issues around tasks, jobs or parts.
Keep engineering comments and decisions around drawings or CAD.
Links validated shop-floor evidence to the exact design feature, attaches its cost and payback, and carries that history into the next revision.
Who it is for
Best suited to manufacturers that repeatedly redesign products they also assemble.
The strongest fit is defined more by the workflow than by the industry.
Products repeat
The business builds the same or similar products often enough for yesterday's workaround to matter to tomorrow's revision.
Design and assembly are separate
The person changing the drawing is not the person holding the tool on the line or bench.
Problems recur
Access, fit, assembly, ergonomic or process issues show up more than once.
Knowledge still travels informally
Important manufacturing knowledge moves through conversations, meetings, messages and individual memory.
Initial focus: signage and displays, print, joinery, furniture, light fabrication and other mid-market engineered-product businesses. The same approach can extend into more complex manufacturing as the platform matures.
Product roadmap
Version 1 is the foundation. Revision replay is what it is built to reach.
Version 1 focuses on capture, validation, feature linking and design history. Later work uses the same verified record set rather than asking customers to recreate their history.
Manufacturing memory
Voice and photo capture, QR context, human validation, feature-level linking, recurrence and cost, design-history views and the reply loop.
Richer engineering context
Drawing-version comparison and carefully bounded depth-capture sessions on known problem assemblies.
Revision replay
Use a customer's own validated history to assess whether a proposed revision appears to remove a known assembly issue, leaves it at risk or needs further engineering review. This is the capability the whole record set is built toward.
Nothing above is built yet: this is the order development follows. Version 1 is funded from documented personal funds. Revision replay is a later research direction, not a Version 1 capability, and every stage before it is designed to stand on its own, using evidence the platform itself will have collected by then, rather than asking a customer to recreate their history.
Founder and advisers
Engineering experience behind the product.
BEng (Hons) Mechanical Engineering from the University of Manchester. Manufacturing and design experience includes GE Vernova, Orbix NDE, Honda and MCR Signs.
He also designed and built Mezbaan, a live multi-tenant property-management SaaS platform with paying customers.
Advisory group
Arif Syed
Co-Founder & CTO, Orbix NDE
MSc Machine Learning, University of London; MPhil Artificial Intelligence, University of Oxford
Platform architecture, AI and vision strategy.
LinkedInProf Lee Margetts
UKAEA Chair of Digital Engineering for Fusion Energy, University of Manchester
Technical strategy, research funding and academic-industry partnerships.
LinkedInDr Akın Ataş
Lecturer in Engineering Design, CEng MIMechE FHEA, University of Manchester
Engineering design guidance.
LinkedInDr Alessandro De Rosis
Senior Lecturer, Mechanical & Aerospace Engineering, University of Manchester
Technical guidance on engineering and computational validation.
LinkedInAndrew Hatcher
Managing Director, The Applied Knowledge Network; Mentor, Cambridge Judge Business School
Investment readiness and fundraising strategy.
LinkedInCurrent stage
Version 1 is in development and early manufacturing pilots are being prepared.
Sclptr is looking for a small number of UK manufacturers to run early paid pilots, each on a single production line. The immediate milestone is to complete Version 1, run those first workflows and measure whether the system is used consistently enough to build a useful manufacturing history.
Pilot with Sclptr
Is there a production problem your team keeps explaining more than once?
Sclptr is preparing its first manufacturing pilots. A good starting point is one recurring workflow where the shop floor knows more about the problem than the current record does.
Sclptr | Manchester, United Kingdom