# Your business has enough moving parts. We take responsibility for the software your operations depend on. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Trusted at scale 20+ clients across 3 continents. Most ask us back when software starts putting the business at risk. ## Find the problem. Make the next release count. We trace the work that is failing, agree what needs to change and take it through to production with your team. ### Diagnose the system We find the broken workflow, weak assumption or missing owner before adding code. ### Look after production We monitor the service, fix faults and keep responsibility clear after launch. ### Choose the route We explain the trade-offs and agree an approach your team can maintain. ### Improve with evidence We use incidents, user feedback and usage data to decide what earns attention next. ## Your company keeps control ### Your code and IP from day one Everything we build lives in your repositories and your cloud, with full admin access. You keep control. ### Know who is responsible Before delivery starts, we agree the scope, record the risks and name the people responsible for decisions. ### Decisions in the same working day UK-hours overlap gives your team time for reviews and the conversations that unblock work. ## Support for each stage of your software Build something new, recover a stalled project, look after production or modernise an existing system. Start with the work your business needs to do. ### [Build](https://sunclue.com/services/build/) Build a new system around a complete user journey. We take responsibility from architecture through release and stabilisation. - First slice: 6 wk - Test gate: 100% - Monitor: Day 1 ### [Rescue](https://sunclue.com/services/rescue/) Recover a stalled build by tracing the failure, protecting useful behaviour and delivering a change the business can verify. - Triage: 48h - Incidents: −68% - Support: 24/7 ### [Own](https://sunclue.com/services/own/) Keep production supported, with named responsibility for maintenance, incidents and the changes your business needs. - Systems: 24 - Uptime: 99.98% - On-call: 24/7 ### [Transform](https://sunclue.com/services/transform/) Modernise the legacy systems quietly slowing your business down, without halting the work that depends on them. - Downtime: 0 - Faster: 3x - Migrated: 100% ## Know what is happening and who is responsible You work directly with engineers who explain their decisions, show progress and stay close to the system after release. ### Clearer technical judgement We explain architecture choices early so you can weigh the cost and consequences before deciding. ### Earlier usable software A small working release gives your team evidence to improve the plan while changes are still manageable. ### Ownership before problems arise Reliability, handover, monitoring and support have an owner before they become a problem. ### Reliable communication UK-hours overlap and written updates keep decisions moving and make the next step clear. ### Continuity after launch The engineers who learn your system stay involved after launch, keeping its history available when the next change arrives. ### AI where it lowers risk We use AI where it saves useful work. Engineers check the result and remain responsible for what reaches production. ## Teams trust us with the work they depend on. Clients bring us difficult systems and return when they need help with the next challenge. 4.9/5 · Helped 20+ companies > We built Alex, Mifu's campaign agent. It plans outreach, tracks performance and handles payments without becoming another dashboard. Alex Asher, CEO at Mifu · London ## Client success stories [Making SAP access easier to trust.](https://sunclue.com/client-stories/sap-authorization/) Too many people had access they no longer needed. Over three years, we helped an enterprise team untangle SAP roles, reduce conflicting permissions and build a routine for keeping access under control. ## Connect the software behind your business. Applications depend on data, infrastructure and the people operating them. We take responsibility across those boundaries. ### Web & Mobile App Development Customer and internal apps with clear architecture, measured performance and release ownership. ### Data & AI Data products and AI workflows that reach production with measurement, review and human accountability. ### DevOps Repeatable releases, production monitoring and cloud infrastructure your team can operate and recover. ### ERP (SAP & Odoo) SAP and Odoo work shaped around the real operating model, then connected carefully to the rest of the stack. ### QA & Testing Checks built into delivery, covering the workflows that must keep working when a release changes the system. ### UI/UX Design Interfaces for complex workflows, designed around the decisions people actually need to make. ## Notes from working on difficult software Practical writing on small releases, recovering stalled builds and keeping systems useful after launch. - [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/): A practical way to choose a valuable, testable finance workflow without giving automation more authority than it can safely carry. - [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/): Use one month of downtime, speed and reject data to estimate lost hours, output and contribution margin without counting the same loss twice. - [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/): Small releases show where the plan is wrong before the budget has disappeared. - [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/): Start with the failure mode, not the loudest feature request. - [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/): Use AI to compress the work around judgement. Do not outsource the judgement. - [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/): The real test is what happens after users, edge cases and Monday morning arrive. ## Before we start working together ### How quickly can diagnosis start? From day one. You see results as we work openly with your team, sharing progress and shaping the next steps together. ### Do you work inside our team? Yes. We work in your tools, take part in relevant team meetings and record decisions where everyone involved can find them. ### How does pricing work? After diagnosis, we agree the scope, responsibilities and pricing in writing. You can see what the engagement covers before committing. ### What about time zone overlap? We keep UK-hours overlap so your team can join reviews, discuss decisions and work through urgent problems with us. ### Who owns the code and IP? You do, from day one. Everything we build lives in your repositories and your cloud accounts, with full admin access and no lock-in. ### Can the engagement grow or shrink? Yes. We review the arrangement as the system stabilises or your needs change, including when your own team is ready to take on more responsibility. ## Software that works. A team that stays. We build and maintain the software your business depends on, working openly with your team from the first day. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) --- [Canonical HTML page](https://sunclue.com/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # The work. The change. The story behind it. A closer look at the problems our clients bring us, the work we do together and what changes along the way. ## [Making SAP access easier to trust.](https://sunclue.com/client-stories/sap-authorization/) Too many people had access they no longer needed. Over three years, we helped an enterprise team untangle SAP roles, reduce conflicting permissions and build a routine for keeping access under control. --- [Canonical HTML page](https://sunclue.com/client-stories/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Making SAP access easier to trust. Too many people had access they no longer needed. Over three years, we helped an enterprise team untangle SAP roles, reduce conflicting permissions and build a routine for keeping access under control. Confidential enterprise client · 3-year partnership · 2022–2024 SAP authorization & access governance The client’s name and identifying details are withheld to protect their confidentiality. ## Results | Measure | Before | After | Reduction | | --- | --- | --- | --- | | Potential access conflicts | 1,973 | 1,194 | 39% | | Recorded access violations | 418 | 346 | 17% | | Vendor master & vendor invoices | 160 | 4 | 98% | | Payments & vendor master | 87 | 4 | 95% | | Posting periods & journal entries | 63 | 26 | 59% | | Credit management & sales orders | 92 | 51 | 45% | Figures reported in the engagement summary are based on SAP GRC extracts covering 19 segregation-of-duties rules across Finance, Procurement and Sales, tracked from 2022 to 2024. Reductions are rounded to the nearest whole percent. These are counts of conflicts, not counts of people or monetary losses. ## When access grows faster than oversight SAP roles had accumulated as the business changed. New requests were approved, permissions overlapped, and there was no consistent process for deciding what should stay. Business users could end up with combinations of access that should have been kept separate. This is a segregation-of-duties problem: one person can carry out steps that should require another person’s involvement. For example, being able to change a vendor’s details and process payments creates a control risk, even when nobody has misused that access. The team also faced recurring access-control audit findings. Fixing individual permissions would help, but without clear ownership and regular reviews, the same problems could return. ## Start with the people behind the roles We began by mapping the authorization landscape and working with business process owners to understand which access people actually needed. The goal was to reduce risk without leaving teams unable to do their jobs. That meant agreeing on naming conventions, documenting role designs and giving each role family a business owner. Access requests and role changes gained a defined review process. Periodic user access reviews gave owners a way to spot permissions that no longer belonged. We then worked through conflicts in order of risk. Some roles could be split or redesigned. Where a conflicting combination could not be removed, the team put compensating controls in place and documented the accepted risk. Those exceptions became something to manage and review, rather than something to lose track of. ## Three years of steady work ### Year one: understand and put foundations in place We assessed the existing risks, began cleaning up roles and established the governance framework. Least privilege, role-based access and consistent naming gave the team shared rules for future decisions. ### Year two: change the roles and the routine The focus moved to critical and high-risk conflicts. We introduced a layered role model, separating base access from additional responsibilities, and supported access lifecycle automation. The first user access review cycle and audit remediation work helped turn the design into day-to-day practice. ### Year three: make the improvements last We consolidated the role catalogue, introduced preventive conflict checks and refined the controls for exceptions. Monitoring and policy updates kept governance aligned with changes in the business. Across the engagement, the team maintained role documentation, conflict reports, review sign-offs and exception logs as audit evidence. Preparing for an audit became part of the ongoing work. ## Less risk, with the remaining work in view Potential conflicts fell from 1,973 to 1,194, a reduction of 39%. Recorded violations fell from 418 to 346, down 17%. The strongest reductions were in two high-risk procurement combinations: vendor master access paired with vendor invoices, and payments paired with vendor master access. Each ended at four potential conflicts. Those measures tell different stories. A potential conflict means someone has the permissions to perform conflicting activities. A recorded violation means the conflicting activities were identified in the activity data. Neither measure, on its own, establishes fraud or financial loss. The work did not remove every conflict. Remaining risks included combinations covered by compensating controls, with continued monitoring and review. The useful outcome was a smaller risk exposure and a clearer process for managing what remained. ## What the partnership left behind Alongside the reductions, the client gained named role owners, a maintained role catalogue, recurring access reviews and a shared evidence library. New requests could be assessed against agreed rules instead of becoming another exception nobody owned. That is why this work benefited from a sustained partnership. Each review informed the next change. Each change became part of the governance routine. The team had a way to keep improving access control as the business moved on. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) [All client stories](https://sunclue.com/client-stories/) --- [Canonical HTML page](https://sunclue.com/client-stories/sap-authorization/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # What can we build together? Sunclue takes responsibility for business software and AI systems, from understanding the work to building and maintaining what is needed. ## [AI agent development](https://sunclue.com/solutions/ai-agent-development/) Focused agents for real business workflows. ## [MCP servers](https://sunclue.com/solutions/mcp-server-development/) Connect AI assistants to your systems. ## [AI company secretary](https://sunclue.com/solutions/ai-company-secretary/) Keep governance work organised and current. ## [WhatsApp AI agents](https://sunclue.com/solutions/whatsapp-ai-agent/) Answer, qualify and route customer enquiries. ## [AI agents for finance](https://sunclue.com/solutions/ai-agents-for-finance/) Research, watchlists and market monitoring. ## [Corporate websites](https://sunclue.com/solutions/corporate-website-development/) A clear, credible home for your business. ## [E-commerce](https://sunclue.com/solutions/ecommerce-website-development/) Stores built around products and customers. ## [SaaS & platforms](https://sunclue.com/solutions/saas-development/) From first useful release to ongoing operation. ## [Brand & portfolio](https://sunclue.com/solutions/brand-and-portfolio-websites/) Let the quality of your work show. ## [EdTech & learning platforms](https://sunclue.com/solutions/edtech-platform-development/) Learning journeys that work across locations. ## [Product & engineering partnership](https://sunclue.com/solutions/remote-development-team-for-uk/) A team that builds with you and owns delivery. --- [Canonical HTML page](https://sunclue.com/solutions/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # AI agent development Give repetitive work a reliable owner. We build agents around a specific job, connect them to your tools and test them against real cases before they reach your team or customers. ## What we deliver - Workflow scoping and tool integration - Answers grounded in your business data - Human approval and escalation paths - Evaluation, tracing and ongoing monitoring ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [MCP servers](https://sunclue.com/solutions/mcp-server-development/): Connect AI assistants to your systems. - [AI company secretary](https://sunclue.com/solutions/ai-company-secretary/): Keep governance work organised and current. - [WhatsApp AI agents](https://sunclue.com/solutions/whatsapp-ai-agent/): Answer, qualify and route customer enquiries. --- [Canonical HTML page](https://sunclue.com/solutions/ai-agent-development/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # MCP servers Make your existing tools usable by AI assistants through a clear, controlled interface. We build Model Context Protocol servers around your APIs and data, with explicit permissions for each action. ## What we deliver - API and database connections - Typed tools and resources - Authentication and scoped access - Testing, deployment and maintenance ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [AI agent development](https://sunclue.com/solutions/ai-agent-development/): Focused agents for real business workflows. - [AI company secretary](https://sunclue.com/solutions/ai-company-secretary/): Keep governance work organised and current. - [WhatsApp AI agents](https://sunclue.com/solutions/whatsapp-ai-agent/): Answer, qualify and route customer enquiries. --- [Canonical HTML page](https://sunclue.com/solutions/mcp-server-development/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # AI company secretary Bring risk registers, meeting records and planning into one workflow. We build governance tools that prepare information and follow-ups for your team to review, with clear ownership of decisions. ## What we deliver - Risk registers and action tracking - Meeting agendas, draft minutes and follow-ups - Targets and forecast workflows - Secure document rooms with controlled sharing ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [AI agent development](https://sunclue.com/solutions/ai-agent-development/): Focused agents for real business workflows. - [MCP servers](https://sunclue.com/solutions/mcp-server-development/): Connect AI assistants to your systems. - [WhatsApp AI agents](https://sunclue.com/solutions/whatsapp-ai-agent/): Answer, qualify and route customer enquiries. --- [Canonical HTML page](https://sunclue.com/solutions/ai-company-secretary/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # WhatsApp AI agents Meet customers on the channel they already use. We connect WhatsApp conversations to your business information and workflows, with a straightforward handover whenever a person needs to step in. ## What we deliver - WhatsApp Business integration - Responses grounded in your own information - Lead qualification and routing - Human handover with conversation context ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [AI agent development](https://sunclue.com/solutions/ai-agent-development/): Focused agents for real business workflows. - [MCP servers](https://sunclue.com/solutions/mcp-server-development/): Connect AI assistants to your systems. - [AI company secretary](https://sunclue.com/solutions/ai-company-secretary/): Keep governance work organised and current. --- [Canonical HTML page](https://sunclue.com/solutions/whatsapp-ai-agent/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # AI agents for finance Reduce time spent moving between feeds and dashboards. We build research and monitoring workflows that organise market information, maintain watchlists and flag changes for your team to assess. ## What we deliver - Market data connections and watchlists - Research summaries with source references - Monitoring and configurable alerts - Review workflows that keep decisions with people ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [AI agent development](https://sunclue.com/solutions/ai-agent-development/): Focused agents for real business workflows. - [MCP servers](https://sunclue.com/solutions/mcp-server-development/): Connect AI assistants to your systems. - [AI company secretary](https://sunclue.com/solutions/ai-company-secretary/): Keep governance work organised and current. --- [Canonical HTML page](https://sunclue.com/solutions/ai-agents-for-finance/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Corporate websites Help customers, partners and prospective employees understand your company. We build fast, accessible websites that explain your products, operations and story, with content your team can maintain. ## What we deliver - Company, product and service pages - Careers and sustainability content - Responsive layouts and search foundations - A content management system suited to your team ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [E-commerce](https://sunclue.com/solutions/ecommerce-website-development/): Stores built around products and customers. - [SaaS & platforms](https://sunclue.com/solutions/saas-development/): From first useful release to ongoing operation. - [Brand & portfolio](https://sunclue.com/solutions/brand-and-portfolio-websites/): Let the quality of your work show. --- [Canonical HTML page](https://sunclue.com/solutions/corporate-website-development/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # E-commerce Give your products a home you control. We build branded stores with clear catalogues, useful search and straightforward buying journeys that work alongside your existing sales channels. ## What we deliver - Branded storefronts and product pages - Catalogue, collections and search - Mobile shopping and checkout journeys - Connections to sales and fulfilment workflows ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [Corporate websites](https://sunclue.com/solutions/corporate-website-development/): A clear, credible home for your business. - [SaaS & platforms](https://sunclue.com/solutions/saas-development/): From first useful release to ongoing operation. - [Brand & portfolio](https://sunclue.com/solutions/brand-and-portfolio-websites/): Let the quality of your work show. --- [Canonical HTML page](https://sunclue.com/solutions/ecommerce-website-development/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # SaaS & platforms Turn a defined business problem into a product people can use. We own the architecture, delivery and operation of your platform, releasing in useful slices and improving it with evidence. ## What we deliver - Web applications and backend services - Accounts, permissions, billing and tenancy - Dashboards and business workflows - Cloud deployment, monitoring and ongoing support ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [Corporate websites](https://sunclue.com/solutions/corporate-website-development/): A clear, credible home for your business. - [E-commerce](https://sunclue.com/solutions/ecommerce-website-development/): Stores built around products and customers. - [Brand & portfolio](https://sunclue.com/solutions/brand-and-portfolio-websites/): Let the quality of your work show. --- [Canonical HTML page](https://sunclue.com/solutions/saas-development/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Brand & portfolio Present your work with the care it deserves. We design and build portfolio websites around your identity, projects and audience, with clear navigation and an easy way to keep the work current. ## What we deliver - Visual direction and website design - Portfolios and case-study layouts - Responsive, accessible development - Content editing for your team ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [Corporate websites](https://sunclue.com/solutions/corporate-website-development/): A clear, credible home for your business. - [E-commerce](https://sunclue.com/solutions/ecommerce-website-development/): Stores built around products and customers. - [SaaS & platforms](https://sunclue.com/solutions/saas-development/): From first useful release to ongoing operation. --- [Canonical HTML page](https://sunclue.com/solutions/brand-and-portfolio-websites/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # EdTech & learning platforms Support learners from their first session through to completion. We build learning platforms around pathways, content and progress, with accessible experiences for people studying across devices and time zones. ## What we deliver - Learner journeys and personalised pathways - Progress and assessment workflows - Content and cohort management - Accessible experiences across devices ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [Corporate websites](https://sunclue.com/solutions/corporate-website-development/): A clear, credible home for your business. - [E-commerce](https://sunclue.com/solutions/ecommerce-website-development/): Stores built around products and customers. - [SaaS & platforms](https://sunclue.com/solutions/saas-development/): From first useful release to ongoing operation. --- [Canonical HTML page](https://sunclue.com/solutions/edtech-platform-development/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Product & engineering partnership Work with a product, design and engineering team that stays close to the business. You see progress from day one, shape priorities with us and retain ownership of your code and infrastructure. ## What we deliver - Product, design and engineering collaboration - Visible progress and shared decisions - UK-hours overlap and clear written updates - Delivery, handover and long-term operation ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All solutions](https://sunclue.com/solutions/) - [AI agent development](https://sunclue.com/solutions/ai-agent-development/): Focused agents for real business workflows. - [MCP servers](https://sunclue.com/solutions/mcp-server-development/): Connect AI assistants to your systems. - [AI company secretary](https://sunclue.com/solutions/ai-company-secretary/): Keep governance work organised and current. --- [Canonical HTML page](https://sunclue.com/solutions/remote-development-team-for-uk/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Software shaped around your work. Software shaped around industry operations. Sunclue works across mining, manufacturing, transport and other sectors. ## [Mining & exploration](https://sunclue.com/industries/mining/) Connect field data, projects and reporting. ## [Manufacturing](https://sunclue.com/industries/manufacturing/) Connect production, inventory and business systems. ## [Transportation & logistics](https://sunclue.com/industries/transportation/) Keep dispatch, customers and operations connected. ## [Finance & investing](https://sunclue.com/industries/finance/) Research and reporting with traceable information. ## [Retail & e-commerce](https://sunclue.com/industries/retail/) Join up storefronts, catalogues and customer service. ## [SaaS & technology](https://sunclue.com/industries/saas/) Build, improve and operate your core product. ## [Education & EdTech](https://sunclue.com/industries/education/) Support learners, educators and remote cohorts. ## [Healthcare](https://sunclue.com/industries/healthcare/) Support staff with clearer administrative workflows. ## [Legal & professional services](https://sunclue.com/industries/legal/) Organise documents, enquiries and client work. ## [Governance & investor relations](https://sunclue.com/industries/governance/) Bring board records and investor information together. ## [Creative & agencies](https://sunclue.com/industries/creative/) Show your work and simplify delivery behind it. --- [Canonical HTML page](https://sunclue.com/industries/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Mining & exploration Keep exploration information useful from the field to the boardroom. We can help mining teams bring project records, sample workflows and reporting into connected systems, with traceable sources and clear review steps. ## Where we can help - Exploration project and document registers - Field observations, sample tracking and assay-data integration - Geospatial data connections and project dashboards - Investor reporting and publication approval workflows ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Manufacturing](https://sunclue.com/industries/manufacturing/): Connect production, inventory and business systems. - [Transportation & logistics](https://sunclue.com/industries/transportation/): Keep dispatch, customers and operations connected. - [Finance & investing](https://sunclue.com/industries/finance/): Research and reporting with traceable information. --- [Canonical HTML page](https://sunclue.com/industries/mining/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Manufacturing Give teams a clearer view of work across the factory and office. We can connect production records, stock and business systems so people spend less time reconciling spreadsheets and more time resolving exceptions. ## Where we can help - Production and inventory dashboards - ERP and supplier-system integration - Quality records and maintenance workflows - Corporate, product and sustainability websites ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Mining & exploration](https://sunclue.com/industries/mining/): Connect field data, projects and reporting. - [Transportation & logistics](https://sunclue.com/industries/transportation/): Keep dispatch, customers and operations connected. - [Finance & investing](https://sunclue.com/industries/finance/): Research and reporting with traceable information. --- [Canonical HTML page](https://sunclue.com/industries/manufacturing/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Transportation & logistics Make information easier to follow as goods and vehicles move. We can build the workflows connecting bookings, dispatch, delivery records and customer updates, shaped around how your operation actually runs. ## Where we can help - Booking and dispatch workflows - Fleet and shipment-data integration - Delivery records and customer updates - Partner portals and corporate websites ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Mining & exploration](https://sunclue.com/industries/mining/): Connect field data, projects and reporting. - [Manufacturing](https://sunclue.com/industries/manufacturing/): Connect production, inventory and business systems. - [Finance & investing](https://sunclue.com/industries/finance/): Research and reporting with traceable information. --- [Canonical HTML page](https://sunclue.com/industries/transportation/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Finance & investing Bring research, market information and reporting into workflows your team can inspect. We build tools that organise evidence and surface changes while keeping financial decisions with the people responsible for them. ## Where we can help - Market monitoring and watchlists - Research aggregation and source-linked summaries - Reporting dashboards and data integration - Access controls and review records ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Retail & e-commerce](https://sunclue.com/industries/retail/): Join up storefronts, catalogues and customer service. - [SaaS & technology](https://sunclue.com/industries/saas/): Build, improve and operate your core product. - [Mining & exploration](https://sunclue.com/industries/mining/): Connect field data, projects and reporting. --- [Canonical HTML page](https://sunclue.com/industries/finance/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Retail & e-commerce Help customers find the right product and give your team a store they can run. We connect brand, catalogue and customer workflows across your own website and the channels you already use. ## Where we can help - Storefronts and product discovery - Catalogue and sales-channel integration - Customer-service and WhatsApp workflows - Order and fulfilment visibility ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Finance & investing](https://sunclue.com/industries/finance/): Research and reporting with traceable information. - [SaaS & technology](https://sunclue.com/industries/saas/): Build, improve and operate your core product. - [Mining & exploration](https://sunclue.com/industries/mining/): Connect field data, projects and reporting. --- [Canonical HTML page](https://sunclue.com/industries/retail/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # SaaS & technology Give a growing product a foundation that can grow with it. We work with your team on platform architecture, customer workflows and reliable releases, from the first useful version through to ongoing operation. ## Where we can help - Product and platform engineering - Account, billing and permission systems - API integrations and AI-assisted workflows - Release pipelines and production monitoring ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Finance & investing](https://sunclue.com/industries/finance/): Research and reporting with traceable information. - [Retail & e-commerce](https://sunclue.com/industries/retail/): Join up storefronts, catalogues and customer service. - [Mining & exploration](https://sunclue.com/industries/mining/): Connect field data, projects and reporting. --- [Canonical HTML page](https://sunclue.com/industries/saas/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Education & EdTech Make learning easier to follow and progress easier to understand. We build accessible experiences for learners and practical tools for the teams organising content, cohorts and assessment. ## Where we can help - Learning pathways and progress tracking - Content and cohort management - Assessment and feedback workflows - Accessible learner portals ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Healthcare](https://sunclue.com/industries/healthcare/): Support staff with clearer administrative workflows. - [Legal & professional services](https://sunclue.com/industries/legal/): Organise documents, enquiries and client work. - [Governance & investor relations](https://sunclue.com/industries/governance/): Bring board records and investor information together. --- [Canonical HTML page](https://sunclue.com/industries/education/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Healthcare Reduce the administrative work around care. We can help teams organise enquiries, internal knowledge and operational information, with access controls and human review suited to sensitive workflows. ## Where we can help - Administrative workflow tools - Internal knowledge search - Staff portals and system integrations - Permissions and review trails ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Education & EdTech](https://sunclue.com/industries/education/): Support learners, educators and remote cohorts. - [Legal & professional services](https://sunclue.com/industries/legal/): Organise documents, enquiries and client work. - [Governance & investor relations](https://sunclue.com/industries/governance/): Bring board records and investor information together. --- [Canonical HTML page](https://sunclue.com/industries/healthcare/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Legal & professional services Keep the information behind professional work organised and accessible. We can connect client intake, document workflows and internal knowledge so your team can find context and keep responsibility clear. ## Where we can help - Client intake and enquiry routing - Document search with source references - Client portals and task workflows - Review and approval controls ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Education & EdTech](https://sunclue.com/industries/education/): Support learners, educators and remote cohorts. - [Healthcare](https://sunclue.com/industries/healthcare/): Support staff with clearer administrative workflows. - [Governance & investor relations](https://sunclue.com/industries/governance/): Bring board records and investor information together. --- [Canonical HTML page](https://sunclue.com/industries/legal/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Governance & investor relations Prepare for meetings and investor questions with current, organised information. We build tools for risk, planning and document management that support the people accountable for governance. ## Where we can help - Risk registers and action tracking - Agendas, minutes and follow-ups - Forecast and reporting workflows - Secure investor document rooms ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Education & EdTech](https://sunclue.com/industries/education/): Support learners, educators and remote cohorts. - [Healthcare](https://sunclue.com/industries/healthcare/): Support staff with clearer administrative workflows. - [Legal & professional services](https://sunclue.com/industries/legal/): Organise documents, enquiries and client work. --- [Canonical HTML page](https://sunclue.com/industries/governance/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Creative & agencies Give creative work a strong digital presence and a practical operating layer. We build portfolios, client experiences and campaign workflows that make your work easier to discover and manage. ## Where we can help - Brand and portfolio websites - Case-study publishing - Client and campaign workflows - Content management and reporting tools ## Working with you, from day one. We start with your team's real workflow and agree the first useful outcome together. You see progress as we build, help shape each release and keep ownership of your code and infrastructure. [Discuss your project](https://calendly.com/petaniweb/petaniweb-introduction) [How we work](https://sunclue.com/#process) [All industries](https://sunclue.com/industries/) - [Education & EdTech](https://sunclue.com/industries/education/): Support learners, educators and remote cohorts. - [Healthcare](https://sunclue.com/industries/healthcare/): Support staff with clearer administrative workflows. - [Legal & professional services](https://sunclue.com/industries/legal/): Organise documents, enquiries and client work. --- [Canonical HTML page](https://sunclue.com/industries/creative/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Notes from working on difficult software Practical writing on small releases, recovering stalled builds and keeping systems useful after launch. ## [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) A practical way to choose a valuable, testable finance workflow without giving automation more authority than it can safely carry. AI in finance · 9 min read ## [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) Use one month of downtime, speed and reject data to estimate lost hours, output and contribution margin without counting the same loss twice. Manufacturing operations · 9 min read ## [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) Small releases show where the plan is wrong before the budget has disappeared. Delivery · 6 min read ## [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) Start with the failure mode, not the loudest feature request. Rescue · 7 min read ## [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) Use AI to compress the work around judgement. Do not outsource the judgement. AI · 6 min read ## [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/) The real test is what happens after users, edge cases and Monday morning arrive. Ownership · 7 min read --- [Canonical HTML page](https://sunclue.com/insights/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Go-live is where ownership starts The real test is what happens after users, edge cases and Monday morning arrive. By Sunclue. Published: 2026-09-12. Updated: 2026-09-12. ## TL;DR Launch is the start of operating a service. Before people rely on it, agree who will notice failures, respond and restore the work that matters. - Name owners and backups, with support coverage the team can sustain. - Monitor real user journeys and rehearse recovery, including partially changed data. - Reserve time for stabilisation and keep accounts, access and operating knowledge with the company. The release is live. The demonstration has gone well. People can sign in, the dashboard loads and the launch message is ready. Then a customer uploads an unexpected file, an overnight job stops halfway through or the person who knows the deployment process takes a holiday. Software becomes part of the business when people depend on it to do their work. At that point, ownership has to cover the days when the system behaves differently from the demonstration. Someone needs to notice the problem, help the people affected and decide what happens next. Those responsibilities are easier to establish before launch, while the team still has the time and attention to test them. ## Give every critical journey an owner Start with the work people must be able to complete. For a manufacturing business, that might include recording a production run, releasing stock or sending an order to the warehouse. Each journey may cross several applications and teams. Name a business owner who can explain the consequence of failure and an engineering owner who can coordinate a response. Add a backup for each. Ownership should survive an absence, a supplier change and the end of the original delivery project. Be specific about coverage. If people depend on an overnight process, an agreement that covers office hours needs an explicit plan for failures outside those hours. Promise the response the team can sustain and make the limits visible to the people using the service. A contact list is only part of the arrangement. The responsible people need access to relevant information, the authority to make appropriate changes and a clear route for decisions they cannot make alone. ## Agree what a working service looks like A server being available does not prove that a customer can complete an order. Define health using the journeys that matter to the business, alongside the technical signals used to investigate problems. For an overnight stock update, useful questions include whether the run completed, whether expected records arrived and whether rejected records can be found. A process may exit successfully while importing an empty file. The team needs to know whether that result is normal for the business. Discuss timeliness too. An update that is correct by lunchtime may still be a failure if warehouse staff need it before the morning shift. Agree the point at which someone should investigate and the point at which the business needs to switch to a fallback process. Google's [guidance on production readiness reviews](https://sre.google/sre-book/evolving-sre-engagement-model/) treats reliability requirements and operational preparation as part of accepting responsibility for a service. A smaller team can use the same basic idea: agree what must be ready and demonstrate it before assuming the system is safely supported. ## Rehearse the awkward morning Choose a plausible failure and walk through it with the people who would respond. Suppose a scheduled import stops after processing part of a file. Who notices? Can support see which records succeeded? Would rerunning the job duplicate anything? Who tells the warehouse whether it can continue? Run technical exercises in an appropriate environment with an agreed scope. The point is to discover missing access, unclear instructions and unsafe assumptions without creating a new incident in production. Keep recovery instructions close to the work. A useful runbook explains the symptom, the checks to perform, the permitted intervention and how to confirm recovery. It should also say when to stop and escalate. A long document that requires its author to interpret it has not transferred much capability. Try the instructions with someone who did not write them. If they cannot identify the affected records or find the right dashboard, improve the material while the details are fresh. ## Plan for the data left behind Rolling back application code may restore the previous behaviour, but it does not automatically undo records already changed by the new version. A failed release can leave duplicate events, partially processed orders or messages that were already sent. Before a risky change, consider both the software and the data. Establish how affected records will be identified and whether the team would reverse, repair or complete the work. Some changes are easier to fix forward than to reverse; the release decision should account for that. The same care applies to restoring a backup. Agree how much recent work the business could lose and what it would take to reconcile records created elsewhere during the interruption. A successful restore is not the end of the recovery if people must still determine which orders are valid. These questions belong in planning because they can change the design. A record of processing progress, for example, may be worth building before launch if it makes an interrupted job recoverable. ## Make room for stabilisation Early operation reveals work that a launch plan cannot fully predict. Users interpret labels differently. Real data contains exceptions. An integration behaves differently at a busy time of day. Reserve capacity for responding to those findings instead of allocating the entire team to the next major feature immediately. Separate defects from new requirements through discussion with the business owner. If the system cannot complete an agreed workflow, the team needs to repair it. If users now want a different workflow, that deserves a deliberate scope decision. Calling every request a bug creates confusion; calling every defect a new feature damages trust. Keep support observations connected to the product backlog. Several tickets about the same confusing field may justify changing the interface. Repeated manual repairs may reveal a missing validation rule or an unreliable dependency. Operations can provide direct evidence for what to improve next. For each recurring issue, record the affected journey and the cost to the people doing the work. That makes a quieter reliability improvement easier to compare with a visible new feature. ## Keep the company able to operate its own software Your repositories, cloud accounts and essential subscriptions should have clear company ownership. Access should be sufficient for the people doing the work and reviewed when responsibilities change. Avoid arrangements where a departed employee or a supplier's personal account is the only route to a critical system. Document the practical dependencies: the domain renewal, the email provider, the scheduled job and the integration credentials. Include who receives billing notices and service alerts. These details are easy to dismiss during development and difficult to ignore when a renewal failure interrupts service. If another team will take over, give them time to operate the system with the original team available. Ask them to perform a routine release and investigate a representative failure. Their questions show what the handover still needs. ## Review ownership as the service changes Set a regular review around a few concrete questions. Which failures affected users? Which interventions keep repeating? Are the agreed support arrangements still appropriate for the way the business now uses the software? What upcoming change could make recovery harder? The review should produce decisions, with owners and dates. Remove alerts that create noise, repair the recurring problem or update the runbook that failed during an incident. If usage has grown, revisit capacity and coverage before the next busy period exposes the gap. Before your next launch, ask someone outside the delivery team to explain what happens when a critical journey fails. Give them the actual contacts and instructions, then let them walk through the response. Anything they cannot resolve is work to finish while the launch team is still together. If that exercise uncovers a system already struggling to support the business, read [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/). ## Keep reading - [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) - [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) - [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) - [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) - [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) --- [Canonical HTML page](https://sunclue.com/insights/go-live-is-where-ownership-starts/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # How much is production loss costing your factory? Use one month of downtime, speed and reject data to estimate lost hours, output and contribution margin without counting the same loss twice. By Sunclue. Published: 2026-09-17. Updated: 2026-09-17. ## TL;DR Take one month of scheduled time, split the missing output into downtime, speed and quality losses, then value it using contribution margin rather than revenue. - Keep downtime, speed and quality losses separate so the same missing unit is counted once. - Call the financial result productive capacity value at risk unless demand and sales evidence prove a realised loss. - Use a range, show every assumption and test one recovery move before asking for a larger system. Production loss rarely arrives as one obvious failure. It shows up as a two-hour stop here, a line running below standard there, a batch sent for rework and overtime needed to catch up. Each event feels manageable. Add them up across four lines and a month, and the missing capacity can be large enough to change a delivery promise, a maintenance decision or an investment case. A big number is easy to produce. A useful one is harder. Operations and finance need to see where it came from, challenge the assumptions and update it when better records become available. This guide shows how to calculate production loss from figures many plants already have. You can follow the formulas below or use the [production loss calculator](https://sunclue.com/tools/production-loss-calculator/) to run the same calculation in your browser. ## Start with the decision the number must support A plant manager may need to decide whether to focus on breakdowns, cycle speed or first-pass quality. A finance director may need to know whether a proposed improvement has enough potential value to investigate. A production planner may need to understand how much output the present schedule can credibly deliver. Those are different decisions. One figure should not pretend to answer all of them. For an initial diagnosis, calculate four quantities: 1. Scheduled line-hours. 2. Units not produced because of downtime, reduced speed and quality loss. 3. Equivalent line-hours of lost productive capacity. 4. Contribution margin associated with that missing output. This creates a common starting point. It does not prove that every missing unit would have been sold, nor that every hour can be recovered. The distinction matters. A 2025 L2L survey of more than 600 US manufacturing leaders reported an average of 30 downtime hours per facility each month, with 60% reporting annual downtime costs above $250,000. It also found that 52% said downtime prevented their organisation from meeting production or shipping targets. The survey shows the scale of the problem, but it does not provide a universal cost per hour for an individual factory. That must come from the factory's own rate, product and margin assumptions. [Read the L2L survey methodology and findings](https://www.l2l.com/news/l2l-report-reveals-impact-of-manufacturing-downtime). ## Establish the production month Begin with comparable lines or machines. Combining equipment with very different rates can produce an average that describes none of them well. If one group makes 100 units per hour and another makes 2,000, calculate them separately and add the final values later. Start with scheduled line-hours: `Lines × working days × shifts per day × productive hours per shift` If four lines run for 25 days, two shifts per day and eight productive hours per shift: `4 × 25 × 2 × 8 = 1,600 scheduled line-hours` Use productive shift hours. Remove planned breaks and planned shutdowns before this calculation. Unplanned stoppages stay in the next step. Theoretical output is: `Scheduled line-hours × sustainable standard output per hour` At 100 units per line-hour: `1,600 × 100 = 160,000 units per month` The standard rate should be achievable under normal conditions. Using the fastest cycle ever recorded inflates every loss that follows. ## Count each loss once Downtime, speed loss and quality loss form a sequence. Calculate them in that order. This stops one missing unit appearing in two categories. ### Downtime loss Add stoppage hours across the selected equipment. If four lines each stop for ten hours, the total is 40 line-hours, not ten clock hours. `Downtime units = total downtime line-hours × standard output per hour` With 96 total line-hours of downtime: `96 × 100 = 9,600 units` ### Speed loss First remove downtime from scheduled hours. Then apply the gap between actual running speed and the standard rate. `Running hours = scheduled line-hours − downtime line-hours` `Speed-loss units = running hours × standard rate × (1 − performance rate)` If the remaining 1,504 line-hours run at 85% of standard: `1,504 × 100 × 15% = 22,560 units` Do not apply the speed gap to downtime hours. No units were expected while the line was already counted as stopped. ### Quality loss Apply the reject and rework rate to the units that the line could produce after downtime and speed loss. `Quality-loss units = running hours × standard rate × performance rate × reject rate` At an 85% running rate and 4% reject or rework rate: `1,504 × 100 × 85% × 4% = 5,114 units` This example produces a total estimated loss of: `9,600 + 22,560 + 5,114 = 37,274 units per month` Against 160,000 theoretical units, the productive capacity gap is 23.3%. The equivalent productive time is 372.7 line-hours because 37,274 units divided by the 100-unit standard rate equals 372.7. Call these line-hours, not factory hours. Four line-hours could mean four machines each losing one hour at the same time. ## Convert output into money without overstating it Revenue is tempting because it produces a larger number. It is usually the wrong starting point. If one unit sells for $50 but consumes $37.50 of variable material, energy, packaging and other incremental costs, the contribution margin is $12.50. Recovering one unit does not create another $50 of economic value if producing it also creates $37.50 of cost. Use: `Productive capacity value at risk = lost units × contribution margin per unit` For the worked example: `37,274 × $12.50 = about $465,900 per month` At the same run rate, that is about $5.59m per year. This is not automatically an accounting loss. Unsold spare capacity may have little immediate cash value. If demand exceeds available output, the number may represent delayed or forgone contribution. If the factory uses overtime, subcontracting or expedited freight to close the gap, those actual costs provide another way to value the problem. Use language that matches the evidence: - **Productive capacity value at risk** when demand evidence is incomplete. - **Contribution delayed** when the output will ship later. - **Contribution forgone** when a specific order was declined or cancelled. - **Avoidable cost** when overtime, subcontracting, scrap disposal or premium freight is recorded. This is more credible than labelling every capacity gap as lost profit. ## Show a range, not false precision Most first-pass inputs are estimates. Downtime logs may miss short stops. The standard cycle may be disputed. Product mix may change the average contribution margin. For the $465,900 monthly estimate, a simple ±10% sensitivity range gives approximately $419,300 to $512,500. The exact centre still appears in the formula, while the headline admits that the inputs are not exact. A range is useful only when its basis is named. “Between $400,000 and $600,000” is not more honest if nobody can explain why those bounds were chosen. For a stronger range, calculate low and high cases from specific assumptions: - Low case: verified downtime only, conservative standard rate and lower-margin product mix. - Central case: most likely operating month. - High case: short stops included, accepted standard rate and higher-margin constrained products. ## Test one recovery move The full loss is rarely recoverable. Test a bounded improvement instead. Suppose the plant asks what happens if downtime falls by 20%. The 96 downtime line-hours become 19.2 recovered hours. Those hours should still be discounted by the current speed and quality performance: `Recovered good units = recovered hours × standard rate × performance rate × (1 − reject rate)` `19.2 × 100 × 85% × 96% = 1,567 good units per month` At $12.50 contribution per unit, that is about $19,600 per month or $235,000 per year of potential recovered contribution. This narrower figure is often more useful than the total. It can be compared with the cost of maintenance work, sensors, spare parts, training, planning changes or a system improvement. This is also the point where manufacturers start comparing the value at risk with the cost of an improvement. Deloitte's 2025 survey of 600 executives at large US manufacturers found that advanced production scheduling was the first or second investment priority for 35% of respondents. Manufacturing execution systems followed at 33%, and quality management at 28%. Respondents reported average improvements of 10% to 20% in production output and 10% to 15% in unlocked capacity after smart manufacturing initiatives. These are survey averages, not promises for an individual site. They do show why manufacturers are connecting operational evidence to investment decisions. [Read Deloitte's survey and methodology](https://www.deloitte.com/us/en/insights/industry/manufacturing-industrial-products/2025-smart-manufacturing-survey.html). BDO found something similar in its 2025 survey of 100 manufacturing CFOs: 48% planned to invest in an advanced planning and scheduling system for their supply chain. [See the BDO Manufacturing CFO Outlook Survey](https://www.bdo.com/insights/industries/manufacturing/2025-bdo-manufacturing-cfo-outlook-survey). ## Put the result in familiar terms Large annual figures are difficult to hold in mind. Comparisons can make them concrete, provided the assumptions remain visible and editable. Using illustrative assumptions of $3,500 monthly operator salary, $50,000 average order contribution, $1m representative machine investment and a $100,000 monthly maintenance budget, the worked example is equivalent to roughly: - 133 operator-months of salary each month. - 9.3 average orders each month. - 5.6 representative machine investments per year. - 4.7 months of maintenance budget each month. These comparisons do not mean the plant should hire 133 operators or buy six machines. They show the scale of the estimated capacity value in terms managers already discuss. Replace each assumption with a local figure before using it in a decision. ## Verify the estimate with one month of evidence An initial calculation should lead to measurement, not directly to a purchase. For one line or product family, collect: - Planned production time with planned breaks removed. - Every unplanned stop, including short stops where practical. - Standard rate and the reason it is considered sustainable. - Actual good units at the end of the process. - Rejects, rework and units later recovered. - Product or product-family contribution margin approved by finance. - Overtime, subcontracting, premium freight and missed-order evidence. Reconcile the loss model with actual good output. If theoretical output minus the three losses does not come close to recorded good output, a category or assumption is missing. Then rank causes inside the largest bucket. “Downtime” is not a root cause. Breakdowns, changeovers, material shortages, waiting for quality approval and missing operators require different responses. ## Let the biggest loss set the next question The calculation should tell you what to investigate next. If downtime dominates, investigate stop reasons, duration and recurrence. If speed loss dominates, compare products, crews and stations before assuming the machine is the constraint. If quality dominates, follow defects back to the first point where the process moved outside its accepted condition. Run your figures through the [production loss calculator](https://sunclue.com/tools/production-loss-calculator/). Keep the formulas with the result. Ask operations to challenge the time and rate assumptions, then ask finance to challenge the margin. Agreement is not required on the first pass. A useful model makes disagreement specific enough to measure. ## Keep reading - [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) - [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) - [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) - [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) - [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/) --- [Canonical HTML page](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # How to rescue a stalled build without rewriting everything Start with the failure mode, not the loudest feature request. By Sunclue. Published: 2026-09-12. Updated: 2026-09-12. ## TL;DR A stalled build needs a diagnosis before a rewrite. Find what blocks a critical user journey and choose the smallest change that restores it. - Prove the team can build, release and recover the current system. - Trace one failure and protect useful existing behaviour while repairing it. - Give recovery a clear stopping point; justify replacement with evidence and migration costs. The build is late. Progress meetings repeat the same blockers. A demonstration works on one laptop, but nobody can explain what it would take to run the product reliably for customers. Someone suggests starting again. A rewrite can feel like relief because it replaces a complicated present with a clean future. Before choosing it, establish what is preventing useful software from reaching users. The answer may be a fragile integration, an unclear decision or a release process that depends on one person. Replacing the application would leave some of those problems untouched. A rescue should produce a clearer picture of the system and a credible next move. That begins with evidence from the work itself. ## Establish what the business needs to recover Ask the business owner to describe the consequence of the delay. Are staff spending hours reconciling records? Is a customer waiting for a promised feature? Does an existing system stop the company accepting more orders? Those answers establish priorities. A product with a broken payment flow and an unfinished settings page has two incomplete features, but the consequences are different. A useful recovery plan makes that difference visible. Choose a short list of outcomes that would demonstrate recovery. For example, a customer can complete an order, the team can release a fix without the original developer and support can identify why a transaction failed. Agree who can accept each outcome. Avoid starting with a new delivery date for the entire old backlog; that turns diagnosis into another promise made without enough information. The outgoing team should be part of this conversation where possible. Ask what they have learned and which decisions remain unresolved. Blame makes people defensive and can remove access to the most useful knowledge in the room. ## Prove that the system can be operated Begin with the current source, deployment process and running environments. Check whether a new engineer can build the application using the documented instructions. Establish which revision is running and where configuration comes from. Find the owner of the infrastructure and the person who can grant appropriate access. If the build cannot be reproduced, investigate that before making broad changes. Otherwise, a local success may have little connection to what customers receive. An undocumented dependency or a manually edited server can invalidate an apparently simple release. Map the main dependencies at the level needed to work safely. Which external services receive data? Which scheduled jobs move records overnight? Which queue can accumulate work? The aim is a usable map with named owners, not an exhaustive architectural report before anyone is allowed to fix a bug. Check how the team would recover from a failed change. A database backup matters only if someone can restore it to an appropriate environment and verify the result. Treat that as controlled operational work: agree the environment, access and recovery objective before running an exercise. ## Trace one failed journey from beginning to end Pick a business-critical failure and follow a concrete example through the system. Start with what the user tried to do, identify the affected record and inspect the points where it changed state. Imagine a warehouse application that sometimes creates duplicate dispatch requests. Rewriting the warehouse interface may do nothing to fix the cause. The problem could occur when a caller retries after a timeout and the receiving service cannot recognise a repeated request. In that example, useful investigation would compare request identifiers, stored records and the timing of acknowledgements. The repair might require repeat-safe processing and a reconciliation workflow for existing duplicates. The exact change depends on the evidence. A screenshot of two duplicate rows is the starting point, not a diagnosis. Keep observations separate from explanations. 'Two requests share this reference' is an observation. 'The mobile app sends twice' is a hypothesis until the request path confirms it. Writing the distinction down makes it easier for another engineer to challenge the theory without reopening every fact. ## Protect the behaviour that already matters A troubled system may still contain years of useful business rules. Some will look odd because the circumstance that produced them is no longer documented. Removing them without checking can turn a recovery project into a new operational problem. For the area you are changing, gather representative inputs and record the outputs that the business expects. Include cases people remember causing trouble: a cancelled order, a partially received shipment or an account with an unusual permission. These examples can become tests around behaviour that must survive the repair. Do not attempt to test every line before improving anything. Concentrate on the journeys with material consequences and the boundaries your change touches. A narrow check that catches a duplicate dispatch is more useful than a large collection of tests that only confirm internal implementation details. When existing behaviour is wrong, agree the correction explicitly. Preserving everything would preserve the defects too. The question is whether the change is understood, accepted and recoverable. ## Compare repair, replacement and removal For each troublesome area, consider the smallest intervention that could meet the agreed outcome. A repair may be enough. A replacement may be justified where the component cannot be supported or its structure blocks necessary change. A feature nobody needs may be removable. There is an established approach to gradual replacement: Martin Fowler's [Strangler Fig pattern](https://martinfowler.com/bliki/StranglerFigApplication.html) describes moving behaviour into new components over time. It gives teams a way to modernise part of a system while the rest continues to serve the business. That option still needs careful data planning. Decide which component owns a record during the transition, how you will compare results and what happens if the new path fails. Avoid allowing two systems to update the same information independently without a deliberate reconciliation design. Our preference is to make a replacement decision at the smallest useful boundary. A reporting component may need to change while order entry remains serviceable. Replacing both at once adds a dependency to the recovery plan unless the business can explain why they must move together. ## Give the recovery a stopping point Unbounded cleanup is an easy way to turn a rescue into another stalled build. Define what the first recovery phase will leave behind: - A repeatable way to build and release the relevant software. - A working critical journey, demonstrated against agreed examples. - A way to detect and investigate the failure being repaired. - Named responsibility for the remaining risks and the next decision. Keep a short recovery log. Each entry should connect a change to the problem it addresses and the evidence used to verify it. This is especially useful when several teams are involved or confidence has been damaged by previous promises. Show unfinished work honestly. 'Order creation is verified; cancellation still needs an agreed rule' is more useful than a completion percentage. It tells the business which decision can help the team move forward. ## When a rewrite earns its place A rewrite may be the right choice when the current system cannot meet an essential requirement and a smaller change is impractical. It may also be reasonable for a small application whose useful behaviour is well understood and cheap to reproduce. Write down the costs beyond new code. Data migration, integration changes, user retraining and the period of supporting both versions all need owners. Include a way to validate the replacement and a decision point at which the business can reassess the investment. The next meeting should end with an intervention that can be reviewed against evidence. Bring the failed journey, the likely cause, the proposed change and the conditions for accepting it. A team can rebuild confidence through that work, one demonstrated result at a time. Use [a deliberately small first slice](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) to turn the recovery decision into a release people can evaluate. ## Keep reading - [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) - [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) - [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) - [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) - [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/) --- [Canonical HTML page](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Where AI earns its place, and where it should stay quiet Use AI to compress the work around judgement. Do not outsource the judgement. By Sunclue. Published: 2026-09-12. Updated: 2026-09-12. ## TL;DR AI earns its place when it reduces the total work, including checking and correcting its output. Start with a specific task and a person who can judge the result. - Keep explicit rules and permissions in ordinary code; use AI where interpretation helps. - Show source evidence and require meaningful approval for consequential actions. - Compare the pilot with the current process, counting review time, errors and running costs. AI is useful when it removes work without making the result harder to trust. That sounds straightforward until a team tries to measure it. A draft produced in seconds may still take ten minutes to check. An assistant that answers most questions may create extra work when nobody can tell which answers need correction. We start with the task and the person responsible for its outcome. What are they doing now? Which part takes time? What would they need to see before accepting the result? Those questions usually produce a more useful brief than a request to add a chatbot. ## Look at the work before choosing the interface Consider a purchasing team that receives supplier updates in different formats. Someone reads each message, finds the order number and proposed delivery date, then updates a record. There may be a useful role for a model in interpreting the message. The date comparison itself can remain ordinary code. So can checking whether the order exists and whether the user has permission to change it. The model's job is the part that needs interpretation; the surrounding application can enforce the rules the business already knows. A first version could show the proposed update beside the original message. A member of the team confirms or corrects it. That gives you a way to observe whether the extraction saves time and which message formats cause mistakes, before letting the system change records automatically. The interface might be a review queue inside existing software. People should not need a conversation to accept a delivery date they can already see. ## Separate an answer from an action A summary and a change to a business record have different consequences. A team may tolerate an imperfect draft that remains private. Sending that draft to a customer or using it to approve a supplier requires a different decision. For each proposed feature, describe what the software can read, what it can prepare and what it can change. Identify the person who can authorise each consequential action. This is easier to inspect than a broad instruction telling the agent to be careful. An approval screen should show enough context to make review meaningful. If a supplier's bank details are changing, presenting only a green confirmation button is inadequate. The reviewer needs to see the proposed change and follow the organisation's established verification process. A model-generated explanation cannot replace that process. Treat incoming documents and messages as information to interpret. Instructions found inside them should not be allowed to redefine the application's permissions or the user's request. Keep the authority to perform an action in the application, where it can be checked and recorded. ## Make the review cheaper than the original job Imagine an internal assistant preparing an exploration-project update. It has access to field notes, a sample register and previous reports. A fluent paragraph alone gives the reviewer more reading to do. A draft linked to the exact source records gives them a route to checking it. Show missing information plainly. If an assay result has not arrived, the assistant should preserve that gap rather than produce a plausible completion. Distinguish the date of the source from the date the summary was generated; a current-looking answer can still be based on an old record. This is a proposed workflow, not a claim that a model can judge geological significance or approve market disclosures. The software can help assemble material while the accountable specialists decide what it means and what may be published. Measure how often a reviewer has to reopen the source, correct a field or discard the draft. If the assistant merely relocates effort from writing to checking, revise the task or stop the experiment. ## Give the trial a fair comparison Run a pilot against the existing way of working. Use comparable tasks and include awkward cases, such as incomplete messages, conflicting dates and requests that belong to another team. Keep a separate set of examples for checking changes so that improving the system does not simply mean tuning it to the demonstration. Record the time spent reviewing and correcting results as well as the model's response time. Include the cost of running the service and maintaining the workflow. A saving on the first attempt may disappear after retries, follow-up questions and manual reconciliation. Some mistakes matter more than others. A slightly clumsy sentence and a wrong account reference should not receive the same treatment in an evaluation. Agree which errors make the result unusable before interpreting an overall success rate. Anthropic's [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) distinguishes predefined workflows from systems in which a model chooses the steps. Its guidance favours starting simply and accepting extra complexity only when the task benefits. For a fixed review process, that supports testing a bounded workflow before introducing a more autonomous agent. ## Know where to leave ordinary software in charge When the inputs and rules are already explicit, a model can add uncertainty without removing much work. Calculating an invoice total, enforcing an access rule or checking that a required field exists usually belongs in code that can be tested directly. Ambiguous requests need a useful fallback. The system might ask a clarifying question, leave a field empty or send the task to a person. Choose the fallback according to the consequence of being wrong. An empty suggestion can be a better result than an answer that sounds complete but cannot be supported. There are also tasks where review is too difficult for the proposed benefit. If the only qualified reviewer must independently repeat the entire analysis to trust it, a narrower use may work better. Let the model organise the documents or find relevant passages while the specialist performs the analysis. ## Decide what would justify expanding it Before a pilot begins, agree what evidence would support a wider rollout. That might be fewer manual corrections for a defined class of messages, faster preparation with unchanged review quality or fewer enquiries waiting for routing. Also agree what would cause the team to pause it. Give someone responsibility for reviewing the system when source material, business rules or model behaviour changes. A workflow that was useful during the pilot can become less useful when the company introduces a new product or changes its approval policy. Pick one repeated task this week and sit with the person doing it. Write down the input, the expected output and how they know the work is correct. If you cannot describe the check, the next step is to understand the job better before automating more of it. Explore [AI agent development](https://sunclue.com/solutions/ai-agent-development/) for the implementation work behind a bounded, reviewable workflow. ## Keep reading - [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) - [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) - [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) - [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) - [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/) --- [Canonical HTML page](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Which finance workflow should become an AI agent first? A practical way to choose a valuable, testable finance workflow without giving automation more authority than it can safely carry. By Sunclue. Published: 2026-09-16. Updated: 2026-09-16. ## TL;DR The best first finance agent is not the most ambitious one. Choose a frequent, bounded workflow with accessible evidence, a reviewable output and a person who owns the decision. - Score the workflow separately for value, practical readiness and control; a high total cannot cancel a critical safety gap. - Begin in shadow or draft mode when an error could move money, alter records or influence a regulated decision. - Measure the complete job, including source gathering, review, corrections, exceptions and ongoing operation. AI agents in finance attract ambitious briefs: close the books, monitor every market signal, answer management questions and resolve exceptions automatically. A useful first deployment is usually much smaller. It takes responsibility for one repeatable piece of work, produces an output somebody can judge and stops before an uncertain result becomes a consequential action. Choosing that workflow is more important than choosing a model. A capable model cannot repair unavailable source data, an undefined approval process or a task whose correct answer exists only in one person's head. This guide gives finance and engineering teams a practical way to compare candidates before committing to a build. You can apply the framework as you read, or use the [finance agent readiness assessment](https://sunclue.com/tools/finance-agent-readiness/) to score one workflow and receive a pilot checklist. ## Start with the work, not the word “agent” Write the proposed job as a trigger, an output and a stopping point. “Build a finance agent” is not a job. These are: - When a new supplier invoice arrives, compare it with the purchase order and receipt, then prepare exceptions for an accounts-payable reviewer. - When a company in the coverage list publishes a filing, collect the approved sources and prepare a cited change note for an analyst. - Each morning, find unreconciled transactions, gather likely supporting records and place proposed matches in a review queue. - Before the monthly review, compare actuals with plan and prepare a draft variance commentary linked to the underlying figures. Each statement names an observable event and a reviewable artifact. None quietly grants permission to pay an invoice, trade a security, post a journal entry or publish a report. This distinction matters because “agent” describes a technical arrangement, not a safe level of authority. Some work needs a model to interpret varied documents or choose among tools. Other work is better handled by rules, queries and conventional automation. The team should be free to use both inside one workflow. ## Test value before feasibility A workflow can be easy to automate and still not be worth operating. Estimate value using the present process rather than a hopeful future one. Look for four signals: 1. **Frequency.** The work occurs often enough to observe and improve. A daily or weekly process gives a pilot more evidence than an annual exercise. 2. **Meaningful effort.** People spend time gathering, comparing, copying or chasing information rather than applying judgement throughout. 3. **A visible delay or error cost.** Slow handling postpones a close, leaves an exception unresolved, delays a decision or causes avoidable rework. 4. **A stable outcome.** The team agrees what useful completion looks like, even when individual cases vary. Count the complete task. If preparing a variance note takes twenty minutes but the analyst spends another hour checking the generated draft, the workflow has not saved forty minutes. Include review, corrections, retries, escalations and the operational cost of keeping integrations and evaluations current. The [ICAEW's examples of finance agents](https://www.icaew.com/insights/viewpoints-on-the-news/2026/jul-2026/four-ai-agent-use-cases-for-finance-teams) concentrate on close and reconciliation, exception handling and finding supporting information. These are useful starting patterns because they contain repeated preparation work and identifiable review points. They are not evidence that every version of those processes should be automated. ## Check whether the evidence is ready An agent needs more than access to a folder or finance system. It needs the evidence required for the job, in forms the workflow can reliably retrieve and relate. Map the source trail for three recent examples. Note where each fact came from, which version was authoritative and how the person doing the work resolved conflicts. Include spreadsheets, messages and personal workarounds; excluding them makes the proposed workflow look cleaner than the real one. Then ask: - Are the required records digital and accessible through a supported interface? - Can the system distinguish current, superseded and missing information? - Do permissions allow the workflow to read only what it needs? - Are there enough accepted examples and difficult exceptions for evaluation? - Can the output link each material claim or proposed action back to evidence? A pile of historic documents is not automatically a useful evaluation set. The examples need a known outcome and enough context to explain why it was accepted. If reviewers frequently disagree, capture that disagreement rather than declaring one answer correct after the fact. Poor readiness does not always reject the idea. It may reveal the first useful project: organise source records, add identifiers, expose a safe API or formalise the review state. That groundwork can improve the current process before any model is involved. ## Treat control as a separate gate Do not average control risk into a single reassuring score. A frequent workflow with excellent data can still be a bad autonomous agent if one wrong action could move money, disclose restricted information or create a misleading record. For each step, separate what the software may **read**, **prepare**, **recommend** and **change**. Then answer five questions: 1. What is the credible worst result when the output is wrong? 2. Can a qualified person review it before that result occurs? 3. Does the reviewer see the evidence and differences needed to make a real decision? 4. Can the action be reversed without hiding the original event? 5. Is one person accountable for the workflow, its permissions and its exceptions? “Human in the loop” is not enough when the human receives fifty unexplained approvals or must repeat the entire analysis. Review must be cheaper than the original work and supported by the right context. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) recommends defining roles, measuring risks and managing them throughout the system lifecycle. Its generative-AI profile also highlights governance, pre-deployment testing, content provenance and incident disclosure. In finance, these ideas become concrete: named owners, source-linked outputs, tested permission boundaries, retained action logs and a known way to pause the workflow. ## Put the candidate into one of four starting positions Value, readiness and control produce a more useful decision than a single percentage. ### Strong pilot candidate The work repeats, consumes meaningful effort and has a stable output. Evidence is accessible. A person can review the result before consequence, and the system can preserve sources and actions. Start with a narrow subset: one entity, document class, ledger or coverage list. Run alongside the current process and compare both routes. ### Pilot after groundwork The value is credible, but records, examples, identifiers or integrations are weak. Fix the smallest missing foundation first. Avoid disguising a data-cleaning project as an agent pilot. ### Assistive mode only The workflow is valuable but an error would be difficult to detect or reverse. Let the system collect evidence, identify candidate exceptions or draft material. Keep posting, payment, publication and regulated decisions outside its authority. ### Choose another workflow The task is rare, its outcome is disputed, review duplicates the work or the benefit depends on removing controls. Find a smaller adjacent job. Sometimes the useful automation is routing documents or maintaining a queue rather than performing the expert decision. ## Example: a research-monitoring workflow Suppose an investment team wants an agent to monitor a coverage list. “Research these companies and tell us what matters” is difficult to test. A narrower job is easier to own: > When an approved company source publishes a new filing or announcement, identify it, compare it with the previous source, and prepare a change note with links and quoted evidence for analyst review. This candidate may score well on frequency, preparation effort and reviewability. It still needs decisions before implementation: - Which sources are approved, and what happens when one is unavailable? - How is a company or security identified across providers? - Which changes belong in the note? - What evidence must appear beside each statement? - How stale may market or reference data be? - Who decides whether the note affects a forecast, recommendation or trade? The agent can organise evidence without becoming an investment decision-maker. That boundary gives the pilot an observable output and keeps responsibility with the analyst. ## Example: supplier-invoice exceptions An accounts-payable team may spend hours matching invoices, purchase orders and receipts. A useful first slice can gather those records, compare defined fields and prepare only the mismatches for review. Straight arithmetic and exact identifier checks should remain deterministic. A model may help interpret varied descriptions, locate supporting correspondence or draft a supplier question. Low-confidence matches should remain visibly unresolved. The pilot should measure more than extraction accuracy. Track the proportion of invoices resolved without reopening sources, reviewer time per exception, incorrect matches, missing-document handling and whether the proposed queue reduces or merely relocates work. Payment release stays outside the first slice. Expansion should depend on evidence from representative invoices, including duplicates, partial deliveries, changed bank details and documents containing irrelevant or adversarial instructions. ## Run a pilot that can produce an honest “no” A pilot is useful when it can disprove the idea before a broad rollout. 1. **Record a baseline.** Measure elapsed time, active effort, exception rate and corrections in the current process. 2. **Assemble representative cases.** Include ordinary work, missing inputs, conflicting records and rare high-consequence cases. Keep a separate evaluation set for later changes. 3. **Begin in shadow mode.** Produce results without changing downstream systems. Compare them with the work people actually accepted. 4. **Introduce explicit review.** Show source evidence, uncertainty and proposed differences. Record corrections and reasons. 5. **Test failure paths.** Remove a source, expire a credential, change a document format and attempt an unauthorised action. Confirm that the system stops usefully. 6. **Agree expansion and stop conditions.** Decide in advance what evidence permits more scope and what result pauses the pilot. Do not promise an arbitrary thirty-day transformation when representative work occurs only monthly or dependencies remain unavailable. Choose a pilot window that contains enough real cases to judge the workflow. ## Use the score as the start of a conversation No questionnaire can decide whether a finance process should become an agent. It can expose assumptions worth testing: where value comes from, which evidence is missing, what authority is proposed and who owns the result. Take one real workflow, not an imagined future platform, and [score its readiness](https://sunclue.com/tools/finance-agent-readiness/). Bring the result to the people who perform, review and operate the work. If they disagree, investigate the disagreement before building. Sunclue designs and operates [bounded AI-agent workflows](https://sunclue.com/solutions/ai-agent-development/) and [finance research tools](https://sunclue.com/solutions/ai-agents-for-finance/) around traceable sources, explicit review and clear ownership. ## Keep reading - [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) - [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) - [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) - [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) - [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/) --- [Canonical HTML page](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Why the first slice should be uncomfortably small Small releases show where the plan is wrong before the budget has disappeared. By Sunclue. Published: 2026-09-12. Updated: 2026-09-12. ## TL;DR Your first release should let someone finish one real job and test an assumption that could change the plan. - Start with one user group and one complete workflow. - Keep access controls, reliable records and recovery in scope, even for a small pilot. - Agree what you need to learn, then let the evidence shape the next release. A project can have a convincing roadmap and still be built around a misunderstanding. The customer may use a different word for the thing you are modelling. An approval may depend on someone who was never invited to the workshop. The data you need may exist only in a spreadsheet on a shared drive. We prefer to discover those problems while the work is easy to change. That is why the first release should feel smaller than the ambition behind it. It needs to put a real piece of work in someone's hands and give the team something concrete to learn from. There is a useful question for an early planning meeting: what could someone complete with the first version, without a developer standing beside them? If the answer is that they can look at several unfinished screens, the scope needs another pass. ## Start with a job someone already does Consider a transport operator replacing an email-based booking process. The full plan might include customer accounts, dispatch, route planning, invoicing and tracking. Each item sounds necessary. Together, they could postpone useful feedback for months. A first release could let one existing customer submit a booking for one route, let a dispatcher accept it and return a confirmation with a reference number. That is a complete journey with a deliberately narrow audience. The team can then watch what happens. Does the customer know the collection address at the point of booking? Does dispatch need a purchase-order reference? Can someone correct a mistake without creating a duplicate job? These questions are much easier to answer with a real booking in front of you. Choose a workflow that happens often enough to observe. A rare annual process may be commercially important, but waiting a year for feedback makes it a poor first learning opportunity unless you can rehearse it with representative records and the people who perform it. ## Make the uncertainty visible Write down the assumption the release is meant to test before adding features to it. In the booking example, it might be: customers can supply enough information for dispatch to accept a job without a follow-up email. That statement gives the team a way to judge the work. A beautiful form that still needs three clarification calls has exposed a problem. It has also produced useful evidence: perhaps the product needs to support a conversation, or perhaps the required fields are wrong. [DORA's guidance on small batches](https://dora.dev/capabilities/working-in-small-batches/) describes shorter feedback cycles as a way to test assumptions and adjust direction. Our practical interpretation is to make each early release answer a business question that can change what the team does next. Avoid choosing the easiest feature simply because it can be finished quickly. Changing a logo or adding a static dashboard may produce a satisfying demonstration without teaching you much about the difficult part of the product. Pick a small job that crosses at least one uncertain boundary: between teams, between systems or between the software and its users. ## Reduce the audience before reducing care There are several ways to make a release smaller. Support one branch before every location. Start with one type of order. Invite a small group of people who can give specific feedback. Keep a complicated exception on the existing process until the new path is understood. These choices need to be visible. Tell users which work the release supports and where to send everything else. If the software silently accepts a job it cannot handle, the apparent simplicity has moved the complexity into someone's working day. Basic care still belongs in the first release. People should be able to access only their own information. Failed submissions should be recognisable. Records need to survive a restart. If something goes wrong, the team needs a way to find the affected job and help the user. The same applies to a manual step behind the scenes. It can be sensible for a dispatcher to approve requests manually before automating the rules. Give that step an owner, a realistic workload and a visible queue. Otherwise, the pilot may look successful because an engineer is quietly doing unpaid operations work every evening. ## Agree what counts as evidence Before releasing, make a short agreement with the people involved: - Name the user and the job they should be able to complete. - State which cases are included and which remain on the existing process. - Choose an observable result, such as a booking accepted without clarification. - Decide how failures will be recorded and who will respond. - Book a review with someone who can change the next release's scope. Measure the whole task. A form submitted successfully is only the beginning if someone must then re-enter its contents into another system. Follow the record far enough to see whether the work became easier or merely moved to a different desk. For a pilot, a modest sample can uncover mistakes without proving that the product works for every customer. Keep that distinction explicit. A route used by familiar customers may hide issues that appear when new customers arrive. The next release can deliberately broaden the conditions rather than treating a quiet pilot as universal validation. ## Let the result change the plan A team gains little from early feedback if every subsequent milestone is already treated as a fixed promise. Leave room for what the first release teaches you. Suppose dispatch accepts most bookings but repeatedly corrects collection windows. The next useful change might be a clearer way to specify times. A more ambitious tracking screen can wait. The decision should follow the observed problem, even if it is less impressive in a slide deck. Record the reason for that choice. A short note linking the change to the affected bookings helps colleagues understand why priorities moved. It also prevents the same debate from restarting when someone revisits the original roadmap. Sometimes the first release reveals that the idea needs a larger change. You may discover that the data cannot support the promised experience, or that the proposed workflow solves the wrong person's problem. Stop expanding that version until the team has addressed the finding. Early evidence is valuable partly because it gives you permission to avoid a much larger investment. ## A useful brief for the first release Bring one recent example of the work to the planning session. Walk through who touched it, what information they needed and where it waited. Mark the point where software could remove a delay or prevent a mistake. Then describe the release in a short paragraph: who will use it, what they will complete, what remains manual and what the team expects to learn. Put the review date beside it. That gives everyone a concrete piece of work to discuss, build and challenge together. For what happens after that first release reaches users, read [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/). ## Keep reading - [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) - [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) - [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) - [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) - [Go-live is where ownership starts](https://sunclue.com/insights/go-live-is-where-ownership-starts/) --- [Canonical HTML page](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Useful tools for difficult software decisions Find where your business is losing time, money or momentum. Get a clear next step. ## [What is lost production capacity costing you?](https://sunclue.com/tools/production-loss-calculator/) Enter one month of figures to see what downtime, slow running and rejects may be costing you. ## [Is this finance task worth automating?](https://sunclue.com/tools/finance-agent-readiness/) Answer 10 questions to see whether a finance task is worth automating and where to start. --- [Canonical HTML page](https://sunclue.com/tools/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Is this finance task worth automating? Answer 10 questions to see whether a finance task is worth automating and where to start. ## What it measures - Value: frequency, effort and operational friction. - Practical readiness: source access, accepted examples and a judgeable outcome. - Control: consequence, review, reversibility and ownership. The assessment gives one of four starting positions: a bounded pilot, focused groundwork, assistive mode only or a different first workflow. [Read the complete workflow-selection guide](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) --- [Canonical HTML page](https://sunclue.com/tools/finance-agent-readiness/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # What is lost production capacity costing you? Enter one month of figures to see what downtime, slow running and rejects may be costing you. ## What it calculates - Scheduled line-hours and theoretical output. - Units and equivalent line-hours lost to downtime, speed loss and rejects. - Productive capacity value at risk, using contribution margin rather than revenue. - Recovery value if downtime is reduced by a chosen percentage. - Operational equivalents using editable assumptions for orders, salaries, machines and maintenance. Every result includes its formula and stays in the browser unless the visitor chooses to email the report. [Read the production loss guide](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) --- [Canonical HTML page](https://sunclue.com/tools/production-loss-calculator/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Help for the work your software needs Sunclue takes responsibility for software development, project recovery and ongoing operation, including the modernisation of existing systems. ## [Build a product people can use](https://sunclue.com/services/build/) Start with one real job your users need to finish. We build the smallest complete release that helps them do it, then use what happens to decide the next step. ## [Keep the software running after launch](https://sunclue.com/services/own/) Running software needs an owner after launch. We agree who watches the important journeys, who responds when they fail and how maintenance fits alongside new work. ## [Get a stalled project moving again](https://sunclue.com/services/rescue/) A stalled build needs a diagnosis before more features. We find what prevents a critical user journey from working and agree the smallest repair that restores progress. ## [Modernise without stopping the business](https://sunclue.com/services/transform/) Replace the parts of a system that slow the business down while protecting the work people still depend on. Migration is a series of controlled changes, each with evidence and a way back. --- [Canonical HTML page](https://sunclue.com/services/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Choose the right approach to the work Compare engineering partners, agencies and internal teams, or weigh repair against replacement. Practical questions for a software buying decision. ## [Engineering partner, agency or in-house team?](https://sunclue.com/compare/engineering-partner-vs-agency-vs-in-house/) Choose a delivery model by the work and responsibility it must cover. A project agency, an engineering partner and an in-house team can all be right; their useful boundaries differ. ## [Repair the system or start again?](https://sunclue.com/compare/rescue-vs-rewrite/) Repair is usually worth testing when useful behaviour can be preserved behind a clear boundary. Replacement deserves consideration when the constraint cannot be removed safely within the current system. --- [Canonical HTML page](https://sunclue.com/compare/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Engineering terms, explained plainly Plain definitions of engineering ownership, software rescue and legacy modernisation, with practical examples and links to further reading. ## [What is engineering ownership?](https://sunclue.com/glossary/engineering-ownership/) Engineering ownership is an agreement about who is responsible for the behaviour and care of a software system. It should make decisions and operating duties clear while keeping the company in control. ## [What is legacy modernisation?](https://sunclue.com/glossary/legacy-modernisation/) Legacy modernisation changes an existing system so the business can keep using it with less risk or friction. The useful starting point is a constraint to remove, rather than the age of the technology. ## [What is a software rescue engagement?](https://sunclue.com/glossary/rescue-engagement/) A software rescue engagement is a bounded investigation and recovery effort for a system or project that is no longer making useful progress. It starts with evidence about the failure, not a predetermined rewrite. --- [Canonical HTML page](https://sunclue.com/glossary/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Build a product people can use Start with one real job your users need to finish. We build the smallest complete release that helps them do it, then use what happens to decide the next step. - First slice: 6 wk - Test gate: 100% - Monitor: Day 1 ## The problem worth solving A roadmap can describe months of features without proving that anyone can complete the work that matters. The expensive misunderstanding is often outside the interface: the records arrive late, an approval depends on another department or a customer cannot provide the information the design assumes. We start with a person doing a specific job. Together we trace the inputs, decisions and result. That gives the team something concrete to build and the business a way to judge whether the release was useful. ## How we build with your team The first release covers a complete journey, including the awkward steps. If someone needs permission to approve a payment or recover an interrupted task, that behaviour belongs in the scope. Decorative features can wait; reliable records cannot. You see working changes as we make them. We explain choices in ordinary language and keep decisions beside the code. Your team helps review the product before each release, using examples from the work rather than a demonstration designed only to look finished. ## Timing and the first release Access, integrations and the work needed to make a release safe affect the plan. We agree the first release date after understanding those dependencies. Useful progress starts on day one: tracing the workflow, exposing an assumption or getting a working environment into your accounts. The first production release follows when the agreed checks pass. We show what is ready and what remains uncertain instead of hiding both behind a percentage-complete report. ## What you keep Your repositories contain the application and its release configuration. Your accounts hold the infrastructure. Tests protect the agreed behaviour, and operating notes explain how to release, observe and recover it. We work through those notes with the people who will use them. Before a pilot grows, we review the evidence: whether people finish the job, where support is needed and what failed. That review sets the next release. See [why a first slice should be small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) for the decisions that make this approach useful. ## After the first release A new product still needs care once real users arrive. We agree responsibility for incidents, maintenance and changes before launch. [Ongoing ownership](https://sunclue.com/services/own/) covers that work; it does not depend on starting a second project to fix every production problem. ## Questions ### What should we bring to the first conversation? Bring a real example of the work, the people involved and what happens when it goes wrong. An existing specification helps, but you do not need a finished brief to start. ### Do we need to know the full scope first? No. We agree the first user journey, the evidence it should produce and the limits on time and cost. Later work follows what we learn, with changes recorded openly. ### Who owns the product and infrastructure? Your company keeps the code, intellectual property and accounts. We work in your repositories and cloud, with access agreed from the start. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Get a stalled project moving again](https://sunclue.com/services/rescue/) - [Keep the software running after launch](https://sunclue.com/services/own/) - [Modernise without stopping the business](https://sunclue.com/services/transform/) [All services](https://sunclue.com/services/) --- [Canonical HTML page](https://sunclue.com/services/build/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Keep the software running after launch Running software needs an owner after launch. We agree who watches the important journeys, who responds when they fail and how maintenance fits alongside new work. - Systems: 24 - Uptime: 99.98% - On-call: 24/7 ## Launch changes the work Once people depend on a service, a broken integration can stop their day even when the application itself is online. Someone needs to notice that failure, understand its effect and restore the work. A handover document alone does not provide that responsibility. We start by mapping the user journeys and the systems behind them. Together we decide which failures need immediate attention, which can wait for working hours and who has authority to make changes during an incident. ## Establish an operating baseline Before taking responsibility, we check access, deployment and recovery. Backups need a demonstrated restore path. Alerts need a person who can act on them. We record external dependencies and the limits of what our team controls. We agree service boundaries and measurement with you before setting targets for your environment. A useful reliability discussion starts with the work users must be able to finish, rather than a percentage detached from their experience. ## Timing and taking responsibility Onboarding follows the state of the system. If nobody can produce a repeatable release or restore a backup, those gaps must be addressed before a confident handover. We show the findings as we go, so you can see the difference between accepted responsibility and work still needed to make it safe. We agree the start of support coverage, escalation contacts and review cadence in writing. There should be no uncertain interval in which the previous team has left and the new team assumes someone else is watching. ## Keep routine work funded Dependencies change, certificates expire and small faults accumulate. We make that work visible in the same planning process as product changes. Incidents lead to proportionate follow-up, with a person and time assigned to each agreed repair. Your team keeps administrative control of accounts. We maintain operating notes as part of changes and practise recovery where a failure would cause material disruption. Read [why ownership starts at go-live](https://sunclue.com/insights/go-live-is-where-ownership-starts/) for the responsibilities to settle before launch. ## When the system needs a larger change Sometimes repeated operational work points to a structural problem. We separate immediate service care from a proposed migration, explain the evidence and agree the additional scope. [Modernisation](https://sunclue.com/services/transform/) then proceeds with continuity of service as an explicit requirement. ## Questions ### Is this a round-the-clock support contract? Coverage is agreed explicitly. Response arrangements, escalation and the systems covered belong in the engagement agreement, including any round-the-clock on-call requirement. ### Can you take over software another team built? Yes, after a review of access, releases, monitoring and recovery. We identify gaps before accepting responsibility and agree what must be repaired first. ### How are improvements prioritised? We review production evidence and business needs with you. Repeated incidents, risky dependencies and work that blocks users compete openly with feature requests for the available time. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Build a product people can use](https://sunclue.com/services/build/) - [Get a stalled project moving again](https://sunclue.com/services/rescue/) - [Modernise without stopping the business](https://sunclue.com/services/transform/) [All services](https://sunclue.com/services/) --- [Canonical HTML page](https://sunclue.com/services/own/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Get a stalled project moving again A stalled build needs a diagnosis before more features. We find what prevents a critical user journey from working and agree the smallest repair that restores progress. - Triage: 48h - Incidents: −68% - Support: 24/7 ## Find the failure before choosing the fix A build may stall because its scope keeps changing, releases are unreliable or a dependency nobody owns blocks the team. Those problems require different repairs. Adding developers before understanding the constraint can make coordination slower without bringing a usable release closer. We inspect the actual path from a change in the repository to a person using it. That includes credentials, environments, release steps and the data the system depends on. We ask what has stopped working and reproduce the failure with your team. ## Protect the useful work Existing behaviour may matter even when the code is difficult to understand. We identify the journeys people rely on and add checks around them before changing the risky parts. The aim is to restore confidence in a release, not to win an argument about a preferred framework. A recovery plan names the first repair, who can approve it and how to back it out. Where replacement is necessary, we move a bounded part of the system and keep a way to compare old and new behaviour. [Repair or rewrite](https://sunclue.com/compare/rescue-vs-rewrite/) explains that decision in more detail. ## Timing and triage The first triage depends on access to the system, logs and people who understand the failure. We agree those dependencies at the start, along with any immediate containment work. Triage produces evidence and priorities. Recovery gets its own stopping point: a journey works, a release can be repeated or an operational fault has been contained and checked. ## Make progress visible You see what we investigated and what changed. We keep a short decision record that distinguishes confirmed causes from remaining questions, so your team can challenge the reasoning without reconstructing a private investigation. We establish an incident baseline and agree the measurement period before assessing the repair. We do not treat a working demo as evidence that production is healthy. ## Leave the system easier to run A rescue is incomplete if the same failure returns when a particular engineer is away. We leave release and recovery instructions, usable monitoring and named responsibility for follow-up work. Read [the stalled-build guide](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) for the practical checks we use before considering a rewrite. ## Questions ### Will you recommend a rewrite? Only when the evidence supports replacement. We first check whether the current system can be built, released and recovered, then compare repair with the cost and risk of moving users and data. ### Can you work with our existing developers? Yes. We investigate with the people who know the system, share findings in your tools and make responsibility explicit. Useful context should stay with the team. ### What happens after diagnosis? You receive a description of the failure, the evidence behind it and a bounded recovery plan. We agree which work to take on before extending the engagement. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Build a product people can use](https://sunclue.com/services/build/) - [Keep the software running after launch](https://sunclue.com/services/own/) - [Modernise without stopping the business](https://sunclue.com/services/transform/) [All services](https://sunclue.com/services/) --- [Canonical HTML page](https://sunclue.com/services/rescue/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Modernise without stopping the business Replace the parts of a system that slow the business down while protecting the work people still depend on. Migration is a series of controlled changes, each with evidence and a way back. - Downtime: 0 - Faster: 3x - Migrated: 100% ## Change the constraint, not just the technology An older system may still do important work well. Its age alone is not a reason to replace it. We start with the cost of the current constraint: releases that take too long, records people re-enter or a dependency that can no longer be maintained. Your team helps identify behaviour that must survive the change. That includes exceptions hidden in spreadsheets or known only to the people operating the service. Understanding them early reduces the risk of a technically successful migration that makes the business harder to run. ## Move through useful boundaries We choose a part of the system that can change without forcing every other component to move at once. An interface, a workflow or a reporting path may provide that boundary. The new part runs against agreed checks before taking over the work. Where practical, old and new behaviour are compared using the same inputs. We investigate differences instead of assuming the new implementation is correct. The approach leaves opportunities to stop, learn and adjust the next step. ## Timing and cutover A migration plan follows dependencies rather than a blanket replacement date. We map the records, integrations and operational windows involved, then rehearse the first transition. Each stage has acceptance checks and a recovery decision that a named person can make. We agree achievable targets and their measurement for your system. We explain when a maintenance window is safer than claiming uninterrupted service without evidence. ## Keep data accountable Moving records is not enough. We check the business meaning of totals, statuses and relationships. Your team agrees reconciliation rules and reviews exceptions. If two systems run together temporarily, we make responsibility for writes explicit so neither becomes an accidental second source of truth. Access controls and audit history need the same attention as application features. We include them in trial migrations and record how a failed cutover would be handled, including any records changed in the meantime. ## Finish the migration The old component stays until the new path has passed the agreed checks and the recovery plan is understood. Then we remove unused infrastructure, update operating notes and confirm who owns the service going forward. [Legacy modernisation explained](https://sunclue.com/glossary/legacy-modernisation/) sets out the terms and trade-offs without assuming a particular stack. ## Questions ### Does modernisation mean replacing everything? No. We identify the constraint and choose a boundary that can change independently. Useful existing components remain in place when replacing them would add cost without solving the problem. ### Can you guarantee no downtime? We plan to keep the business working during migration, but uninterrupted service depends on the system. We agree cutover constraints, rollback and any required maintenance window before delivery. ### How do you know the migrated data is right? We agree reconciliation rules with the people responsible for the records. Trial migrations compare counts and meaningful business values, including exceptions, before the final cutover. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Build a product people can use](https://sunclue.com/services/build/) - [Get a stalled project moving again](https://sunclue.com/services/rescue/) - [Keep the software running after launch](https://sunclue.com/services/own/) [All services](https://sunclue.com/services/) --- [Canonical HTML page](https://sunclue.com/services/transform/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Engineering partner, agency or in-house team? Choose a delivery model by the work and responsibility it must cover. A project agency, an engineering partner and an in-house team can all be right; their useful boundaries differ. ## Start with the responsibility you need If you need a defined piece of work delivered by a date, a project engagement may fit. If you need people who build context inside the business over years, an in-house team deserves serious consideration. If an important system needs sustained technical responsibility while your company retains control, an engineering partnership may be useful. These are engagement models, not reliable labels for individual suppliers. Some agencies operate services for years; some partnerships sell only time. Read the proposed responsibilities before inferring them from the name. ## Compare the working arrangements | Question | Project agency | Engineering partner | In-house team | | --- | --- | --- | --- | | What is usually being bought? | An agreed project or set of deliverables | Responsibility for an agreed area of software | People and capability within the company | | Who directs priorities? | Client lead within the project agreement | Client and partner within agreed service boundaries | Company management and product leadership | | What happens after launch? | A separate support arrangement may be needed | Operation can be part of the original agreement | The company must allocate operating capacity | | What needs careful checking? | Acceptance, change control and handover | Decision rights, coverage and exit arrangements | Hiring, retention, management and coverage | ## When a defined project fits A clear website, isolated integration or bounded product release may suit a project agency. The boundary helps both sides agree what completion means. It becomes less useful when the business expects ongoing incident response but the agreement ends at acceptance. Ask who will own the repository and accounts, what happens when requirements change and how another team could take over. A low initial price tells you little about those arrangements. ## When a partner fits A partnership fits work that needs context carried from diagnosis into delivery and operation. Sunclue's [four service models](https://sunclue.com/services/) describe those responsibilities. You should still expect a written boundary: ownership does not mean unlimited work, guaranteed outcomes outside the team's control or the loss of your company's decision rights. Review the actual operating arrangement. Who can authorise a production change? Who responds when the integration fails? How is a disagreement about priorities resolved? Clear answers matter more than a promise to be an extension of your team. ## When to invest in an in-house team An internal team can build deep knowledge where software is central to the company's strategy. It also needs leadership, recruitment and time for maintenance. Hiring one developer does not automatically create resilient service coverage. A partner can help during recruitment or take on work with a clear boundary while the internal team keeps product direction. Avoid splitting responsibility so finely that every incident becomes a discussion about whose contract covers it. ## Make the decision with the full cost visible Compare a plausible year of work, including releases, support and knowledge transfer. Count the management time your company supplies. Ask each option to describe how it handles a failed release and how you can leave the arrangement. There is no universal winner. Choose the model whose responsibilities match the work, and revisit it when that work changes. ## Questions ### Is an engineering partner always cheaper? No. Cost depends on scope, seniority, coverage and how much management the work needs. Compare the complete cost of delivery and operation, including time from your own team. ### Can these models work together? Yes. An in-house team can own the product while a partner takes responsibility for a bounded migration or service. The important part is agreeing decisions, interfaces and escalation. ### What should a proposal make explicit? It should name the outcome being bought, the people responsible, what the fee covers and what happens after release. Compare exclusions as carefully as deliverables. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Repair the system or start again?](https://sunclue.com/compare/rescue-vs-rewrite/) - [Build a product people can use](https://sunclue.com/services/build/) - [Keep the software running after launch](https://sunclue.com/services/own/) [All comparisons](https://sunclue.com/compare/) --- [Canonical HTML page](https://sunclue.com/compare/engineering-partner-vs-agency-vs-in-house/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # Repair the system or start again? Repair is usually worth testing when useful behaviour can be preserved behind a clear boundary. Replacement deserves consideration when the constraint cannot be removed safely within the current system. ## Separate frustration from the constraint A troubled system produces understandable frustration. Slow releases, unreliable tests and recurring incidents make a clean start attractive. But a new implementation still has to reproduce the business rules, handle existing records and support the people doing the work. Start by describing the actual constraint. Is a particular integration unreliable? Can the team release a change without manual steps? Is a platform reaching the end of support? A specific failure makes options comparable. ## What a repair must prove A repair should restore useful behaviour and make the next change safer. That might mean introducing a repeatable build, protecting a critical journey with tests or replacing one failing integration. [Software rescue](https://sunclue.com/services/rescue/) starts by checking those possibilities. The experiment needs a boundary. Name the journey that will work, the evidence to collect and the time available. If the repair keeps expanding without bringing a release closer, stop and revisit the decision. ## What a rewrite must account for A rewrite includes discovery, implementation and migration. It may also require a period of running two systems, reconciling data and supporting users through a changed workflow. Those costs belong in the proposal from the start. Existing behaviour is often poorly documented. Observe real work and record exceptions before treating the current code as disposable. A cleaner architecture is useful only if the replacement still does the job. ## Compare complete options | Consideration | Bounded repair | Replacement | | --- | --- | --- | | Existing behaviour | Preserved and checked around the change | Must be discovered and reproduced or deliberately retired | | Data movement | Often limited to the affected boundary | Requires explicit migration and reconciliation | | First useful evidence | A critical journey works or releases become repeatable | A replacement path works with representative records | | Recovery | Back out the repair or contain its effect | Restore the old path and handle records changed since cutover | ## Prefer staged replacement where it helps Repair and rewrite are not the only two end states. A system can keep useful components while replacing the part that creates the constraint. This is often the practical route for [legacy modernisation](https://sunclue.com/services/transform/). Staging only helps if the boundaries are real. Agree where records are written, how the parts communicate and when the old component can be retired. Otherwise two systems can double the operating work without reducing the original problem. ## Record the decision and its limits Write down why the chosen path is better, what remains uncertain and what would change the decision. Include the cost of keeping the business running while the work happens. Revisit those assumptions when evidence changes, rather than defending a technical direction because delivery has already started. ## Questions ### Is difficult code enough reason to rewrite? No. Difficult code creates cost, but a rewrite also requires rediscovering behaviour and moving users and data. Compare a bounded repair with the full replacement work. ### What if the current platform is unsupported? That creates a concrete reason to change, especially where security or recovery is affected. It still does not determine whether the safest path is gradual replacement or a single cutover. ### How do we avoid an endless rescue? Define a stopping point and budget for the investigation. Agree what evidence would justify repair, replacement or pausing the work before more delivery begins. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Engineering partner, agency or in-house team?](https://sunclue.com/compare/engineering-partner-vs-agency-vs-in-house/) - [Get a stalled project moving again](https://sunclue.com/services/rescue/) - [Modernise without stopping the business](https://sunclue.com/services/transform/) [All comparisons](https://sunclue.com/compare/) --- [Canonical HTML page](https://sunclue.com/compare/rescue-vs-rewrite/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # What is engineering ownership? Engineering ownership is an agreement about who is responsible for the behaviour and care of a software system. It should make decisions and operating duties clear while keeping the company in control. ## Make responsibility observable Ownership becomes useful when people can see what it requires. A named person reviews a risky change. An alert reaches someone with authority to act. A failed release has a recovery path that the team has practised. None of those duties should rely on an assumption that someone else is handling them. ## Agree the boundaries A practical agreement identifies the systems covered, working hours, escalation and the decisions the team can make. It also records dependencies outside the team's control. Responsibility for an application does not grant authority over every third-party service it uses. The company should retain access to repositories and infrastructure. Shared operating knowledge makes the arrangement resilient when a person is away or the commercial relationship ends. ## Use the term carefully Ownership is not a promise that no incident will happen. It is a commitment to prepare, respond and learn within an agreed scope. Ask for the operating details behind the word: who notices failure, who restores service and who funds the follow-up work. [Ongoing software ownership](https://sunclue.com/services/own/) describes how Sunclue approaches those duties. [The go-live guide](https://sunclue.com/insights/go-live-is-where-ownership-starts/) covers the questions to settle before users depend on a new release. ## Questions ### Does ownership mean the supplier owns our code? No. In Sunclue engagements, your company keeps the code, intellectual property and accounts. Engineering ownership describes responsibility for the work, not ownership of your assets. ### How is it different from support? Support may cover incidents within a defined service window. Engineering ownership can also cover technical decisions, delivery and maintenance. The written scope determines what is included. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [What is a software rescue engagement?](https://sunclue.com/glossary/rescue-engagement/) - [What is legacy modernisation?](https://sunclue.com/glossary/legacy-modernisation/) - [Keep the software running after launch](https://sunclue.com/services/own/) [All glossary](https://sunclue.com/glossary/) --- [Canonical HTML page](https://sunclue.com/glossary/engineering-ownership/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # What is legacy modernisation? Legacy modernisation changes an existing system so the business can keep using it with less risk or friction. The useful starting point is a constraint to remove, rather than the age of the technology. ## Identify what needs to change A release process that depends on one person, an unsupported dependency or repeated manual data entry can justify modernisation. Each points towards different work. Replacing a whole platform without identifying the constraint risks moving the same problem into newer technology. ## Preserve business meaning Existing records and unusual workflows often contain decisions that never reached a specification. Observe the work and agree what must survive. A migration should check meaningful totals and relationships, not only whether the transfer completed without an error. ## Plan for coexistence and recovery Staged migration can reduce the size of each change. It also creates temporary complexity when old and new components run together. Make the source of truth explicit and decide how changes made during a failed cutover would be recovered. The final step is retiring the old path once the agreed evidence supports it. Until then, somebody still has to operate it. [Sunclue's modernisation service](https://sunclue.com/services/transform/) explains the work around that transition, while [repair versus rewrite](https://sunclue.com/compare/rescue-vs-rewrite/) helps frame the initial decision. ## Questions ### Does legacy mean obsolete? No. An established system can remain useful and well supported. Modernisation becomes worthwhile when a specific constraint, cost or risk justifies changing it. ### Can a migration happen gradually? Often, if part of the system can change behind a clear interface. The team must agree data ownership, comparison checks and recovery at each stage. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [What is engineering ownership?](https://sunclue.com/glossary/engineering-ownership/) - [What is a software rescue engagement?](https://sunclue.com/glossary/rescue-engagement/) - [Modernise without stopping the business](https://sunclue.com/services/transform/) [All glossary](https://sunclue.com/glossary/) --- [Canonical HTML page](https://sunclue.com/glossary/legacy-modernisation/) · [Sunclue reading guide](https://sunclue.com/llms.txt) # What is a software rescue engagement? A software rescue engagement is a bounded investigation and recovery effort for a system or project that is no longer making useful progress. It starts with evidence about the failure, not a predetermined rewrite. ## Investigate the delivery path The team needs to understand how a change reaches a user. Missing access, unreliable environments or unclear approval can block progress even when the application code is sound. A rescue checks those conditions alongside the reported fault. ## Write a bounded recovery plan A useful plan names the failure, the evidence behind the diagnosis and the first repair. It also states how the team will check the result and recover if the change makes matters worse. Without a stopping point, rescue can turn into an undefined replacement project. The people already working on the system hold valuable context. Investigate with them and preserve useful behaviour before changing the parts that are difficult to understand. ## Separate recovery from improvement Restoring a release path may expose further work. Record it, but distinguish what is necessary for recovery from what would make the system nicer to maintain. That distinction lets the business choose the next investment with clearer information. See [Sunclue's rescue service](https://sunclue.com/services/rescue/) for the engagement approach, and [repair versus rewrite](https://sunclue.com/compare/rescue-vs-rewrite/) for the trade-offs when the first investigation points towards replacement. ## Questions ### Is rescue only for broken production systems? No. A project can need rescue before launch when the team cannot produce a usable release. The investigation should establish what prevents progress and whether the current work can be recovered. ### What marks the end of a rescue? An agreed recovery condition, such as a critical journey working or a repeatable release with a tested recovery path. Ongoing operation and additional features need their own scope. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [What is engineering ownership?](https://sunclue.com/glossary/engineering-ownership/) - [What is legacy modernisation?](https://sunclue.com/glossary/legacy-modernisation/) - [Get a stalled project moving again](https://sunclue.com/services/rescue/) [All glossary](https://sunclue.com/glossary/) --- [Canonical HTML page](https://sunclue.com/glossary/rescue-engagement/) · [Sunclue reading guide](https://sunclue.com/llms.txt)