Frequently asked questions
Straight answers on scope, control, proof, data and cost. If yours isn't here, bring it to the call.
For business leaders
Fabrica is a technology renewal service in development, built by Thinslices. It observes how a production system behaves, turns that evidence into a reviewed System Specification, rebuilds selected workflows on a modern architecture, proves them against the running system and shifts production one workflow at a time.
No. Keeping a stable system, upgrading it or refactoring a narrow part may be the better investment. Fabrica's reconstruction approach is for cases where replacement earns its place. Ongoing renewal aims to reduce the build-up of deferred change, not to remove all future migration work.
Thirty minutes on one business priority, the system behind it and the constraints on changing it. We identify a useful first scope and what a technical review would need to establish. No production access is needed.
A CEO, president, founder or CFO can sponsor the conversation. Your CTO or engineering leader partners on scope, evidence and acceptance. Your technical team decides when to shift each workflow.
The proposed model starts with an assessment and a bounded pilot, then a recurring plan for agreed priorities. Each cycle refreshes the evidence and specification, delivers selected changes and verifies outcomes. Scope, cadence, fees and exceptions are agreed before commitment.
Pricing depends on scope and is set after an assessment. The assessment fee is agreed before work starts. We are testing two models, an assessment-first route and a renewal subscription, and do not publish a list price while the service is in development.
For technical leaders
Not by default. Parallel builds and incremental replacement do not need a whole-system freeze. If a freeze is needed for a specific scope, for example during a data cutover, we agree what it covers and how long it lasts. Our target is days or weeks for an agreed scope, and a pilot measures it.
Both implementations are compared against the same specification. We replay or shadow representative workloads with side effects controlled, and check business outcomes, data integrity, reports, permissions and performance. Differences are investigated and resolved before any traffic moves.
Data cutover is a separate workstream. Before live writes route to the new implementation, we define mappings, backfill and sync, write ownership, reconciliation and rollback. Important report totals are reconciled against the current system.
The first call needs no access. An assessment needs read-only access to code, schema and available analytics, agreed with your technical team. Sensitive payloads are redacted, collection overhead is measured and collection failures are kept off the request path.
We are starting with web applications built on Ruby on Rails, typically backed by PostgreSQL. Java Spring, .NET Framework, PHP and Django systems can be discussed on request.
In your repository. Every change arrives as a reviewed pull request, and you choose where it runs.
Each shift has acceptance criteria and a tested rollback. The current system keeps running until a workflow has been fully moved and verified, so rolling back is a routing change rather than a redeploy.
Book a 30-minute conversation about one priority and the system behind it. You leave with a practical first step.