|
B2B expansion go-to-market
A Zurich compliance-software company (CHF 24M ARR, growth down from 45% to 18%) gets CHF 5M over 18 months to open Germany, the UK and Singapore against two competitors with ten times its sales force, with four salespeople, six marketers and a product that needs four months of localisation per market. Ten signed...
fe358b6343ccbeae · marketing_b2b_expansion.json
A B2B software company in Zurich (180 employees, CHF 24M ARR, growth down from 45% to 18%) sells a compliance and audit platform to private banks, cantonal banks and insurers in Switzerland and Liechtenstein: 140 customers, net revenue retention 108%, a seven-month sales cycle, CHF 170k average contract. It has just released an ESG-reporting add-on that 30 customers use and analysts rate above the leaders'. The board approves CHF 5M over 18 months to open Germany, the UK and Singapore, where the company has no brand, no references, and two competitors with ten times its sales force; CAC at home is CHF 110k with a 14-month payback. Assets: four salespeople, six marketing people (mostly content and events), a partner programme with three consultancies at home, and a product that needs four months of localisation and regulatory mapping per market. Constraints: growth at home must not drop, the marketing team cannot double, and the board wants a first proof — ten signed customers abroad — within 12 months before releasing the second half of the budget. Plan the go-to-market: which markets first and why, the positioning against the two leaders, the channel and partner strategy, how the budget is split and staged, what is measured monthly, and what would make you stop or change course. |
Marketingplan
B2B software, Zurich
|
Words214 | Runs | Last run |
|
A ten-year-old Java monolith (2 million lines, one 1.2 TB PostgreSQL database with 350 tables and stored procedures, 40,000 orders a day with 12x peaks in sales) serving eight countries, with five teams committing to one repository and 25% test coverage. Plan its migration to independently deployable services over...
b5612cc6d1376aa0 · ecommerce_monolith_migration.json
A mid-size European fashion retailer runs its e-commerce on a 10-year-old monolith: Java 8 / Spring, about 2 million lines, one PostgreSQL database of 1.2 TB with 350 tables and heavy use of stored procedures and cross-module joins. It serves 8 countries, 3 currencies and 4 languages, with about 40,000 orders a day and peaks of 12x during sales. The monolith contains: the storefront (server-rendered, plus a separate mobile app hitting the same endpoints), catalogue and search (a Lucene index rebuilt nightly), pricing and promotions (the most complex module, 200,000 lines, with country-specific rules nobody fully understands), cart and checkout with three payment providers, order management, inventory synchronised every 15 minutes with the warehouse system via file exchange, customer accounts and loyalty, returns, and a back-office used by 300 staff. Deployments happen every two weeks as a single artefact with a 30-minute maintenance window; test coverage is 25% and mostly unit tests. Five teams of 8 developers, each organised around a business area but all committing to the same repository. Plan the migration to independently deployable services over 12 months with no feature freeze, no unplanned downtime and the ability to roll back every step, preserving the peak-season capacity (sales in January and July must not be put at risk). |
Softwareplan
European fashion e-commerce
|
Words210 | Runs2 2 of 2 completed 3 analyses |
Last run2026-09-1902:49 |
|
Security and compliance plan
A London healthtech SaaS (95 engineers, 40 hospital groups and insurers as customers) receives a penetration test from its largest prospect: 4 critical findings (patient documents visible across tenants, secrets in a public repository, no MFA on the admin panel, old CVEs) and 17 high ones. The prospect wants the...
e9bd4fb5057adab9 · software_security_compliance_plan.json
A healthtech SaaS in London (95 engineers, 40 customers that are hospital groups and insurers in the UK and Germany, £18M ARR) has grown fast on a Django monolith plus 40 services, with a platform team of five. A penetration test commissioned by its largest prospect (a £3M contract) found 4 critical and 17 high findings: an IDOR exposing patient documents across tenants, secrets in the history of a repository made public by mistake, no MFA on the admin panel, unpatched dependencies with known CVEs (the oldest three years old), over-privileged AWS IAM roles, and no audit log of who read what. There is no SOC 2 or ISO 27001; customers ask for both, and the prospect requires the critical findings fixed within 30 days and SOC 2 Type II evidence within 9 months. Engineering ships weekly; 60% of the teams' capacity is committed to a roadmap already sold to customers; there is one part-time security lead; the board will not fund more than four hires. Plan the next 9 months: the order in which the findings are fixed and by whom; how the criticals are closed in 30 days without stopping the roadmap; the controls and evidence needed for SOC 2 Type II (and what ISO 27001 would add); the changes to the development process that keep the findings from coming back (secrets, dependencies, access, logging, tenant isolation, security testing in the pipeline); what the four hires are and what is bought instead of built; how the capacity is negotiated with product; and the monthly milestones the prospect and the board can check. |
Softwareplan
healthtech SaaS, London
|
Words264 | Runs | Last run |
|
Cash management process
An Ohio industrial group negotiating a covenant waiver ($105M facility, net debt/EBITDA about to breach) forecasts cash once a month in a spreadsheet and discovered its last two breaches of the cash floor when a supplier payment bounced. The lenders demand a rolling 13-week forecast every Monday and a monthly...
5f8a68dba170b2db · finance_cash_management_process.json
A family-owned industrial group in Ohio (three plants, 1,100 employees, $340M revenue, EBITDA margin down from 9% to 4% in two years) makes components for the automotive and appliance industries and is negotiating a covenant waiver on its $105M senior secured credit facility (net debt/EBITDA at 3.4x against a 3.5x limit, 4.6x forecast at the next quarterly test), with a $45M asset-based revolver 85% drawn and $20M of supplier payables past due. Cash is forecast once a month by the treasurer, in a spreadsheet built from the ledger three days after month end; the plants report shipments and purchases weekly by email; nobody reconciles forecast with actuals; the covenant ratios are calculated by the auditors at quarter end; the last two breaches of the $10M cash floor were discovered when a supplier payment bounced. The lenders make the waiver conditional on a rolling 13-week cash-flow forecast every Monday and a monthly covenant projection, both with variance explanations. Define the cash management process that meets that condition and runs the company on cash: the 13-week forecast (who provides which inputs, when and at what detail, how they are validated and reconciled with actuals), the weekly cash committee (participants, agenda, the decisions it can take and their limits: payment prioritisation, revolver draws, capex releases), the monthly covenant projection with its early-warning thresholds and escalation, and the controls and reports for the lenders — with roles, cadence, tools, and the rules that decide who gets paid when cash is short. |
Financeprocess
industrial group, Ohio
|
Words247 | Runs | Last run |
|
A New York payments platform (260 engineers in 28 teams, $4B a month, a 99.95% SLA) had 31 customer-impacting incidents in a year: customers detected 40% of them first, $1.3M went in SLA credits, nobody was in charge for an hour twice, 3,400 alerts a month are 85% noise, on-call exists in 12 teams and is unpaid,...
52c3ad01110cde42 · software_incident_management_process.json
A B2B payments platform in New York (260 engineers in 28 teams, 2,100 customers, $4B processed a month, a 99.95% SLA with service credits) runs about 180 services on Kubernetes across two AWS regions, with a shared PostgreSQL cluster for the ledger. In the last 12 months: 31 customer-impacting incidents, median time to detect 22 minutes (customers detected 40% of them first), median time to mitigate 3 h 10 min, $1.3M paid in SLA credits, two incidents in which nobody was sure who was in charge for over an hour, and a CEO email about "outages we hear about from clients". On-call exists in 12 of the 28 teams, unpaid, fed by alerts from six different tools — 3,400 alerts a month, 85% of them noise; there is no severity scale, status-page updates are written by whoever is around, and postmortems happen for some incidents, in various formats, with action items that are rarely tracked (11 of 64 closed). A SOC 2 Type II audit in eight months will test incident response. Engineers push back against "carrying a pager for other teams' code". Define the incident management process: severity levels and what each one triggers; roles (incident commander, communications, scribe, subject-matter responders) and how they are staffed 24x7 across 28 teams; the on-call structure, rotations, compensation and the rules for alert quality; detection and escalation paths; internal and customer communications (status page, account managers, regulators when required) with their timings; postmortems (when mandatory, format, blameless review, ownership and tracking of actions); the metrics and reviews that show whether it works; and how it is introduced across the teams without waiting for the audit. |
Softwareprocess
B2B payments platform, New York
|
Words273 | Runs2 2 of 2 completed 2 analyses |
Last run2026-09-2102:48 |
|
Promotion process
A grocery chain of 140 supermarkets in the North of England runs promotions worth 22% of its sales by accretion: 14 category managers plan in spreadsheets, guess the uplift, allocate stock by fixed percentages, and nobody knows which promotions made money once funding, cannibalisation and waste are counted;...
e44e6c5b34b502eb · retail_promotion_process.json
A grocery chain with 140 supermarkets (6,000 to 25,000 sq ft) across the Midlands and the North of England, £1.7B of sales and a 26% gross margin, runs promotions worth 22% of its sales with a process that has grown by accretion: 14 category managers plan each promotion eight weeks ahead in spreadsheets, negotiate the supplier funding one by one, estimate the uplift by guesswork, allocate the stock to stores by a fixed percentage regardless of local demand, and evaluate nothing beyond total sales; stores learn of a promotion ten days ahead and order by hand; out-of-stocks reach 14% during promotions, 40% of the leftover stock is marked down, and nobody knows which promotions made money once funding, cannibalisation and waste are counted. Data: three years of till receipts at line level, store deliveries and supplier funding agreements; stock records wrong for 30% of the SKU-store combinations audited. 18 people in supply-chain planning, 14 category managers, 140 store managers, and one IT team of six with half its capacity committed to an ERP go-live in nine months. Define the end-to-end promotion process, from proposal to post-evaluation: stages, gates and decision rules (which promotions are approved, on what expected margin), who forecasts the uplift and how the forecast is checked against history, how stock is allocated to 140 stores and replenished during the event, what the stores do and when, how the outcome is measured (uplift, cannibalisation, waste, margin net of funding) and fed back into the next cycle — with roles, cadence, systems, and the controls that stop a bad promotion before it reaches the shelf. |
Retailprocess
grocery chain, North of England
|
Words266 | Runs | Last run |
|
Surgical waiting-list procedure
An NHS trust has 9,400 patients waiting for surgery, 2,100 beyond 52 weeks; the list is scheduled from paper by date of referral, validated once a year, pre-assessed by phone two days before surgery; 12% of theatre sessions are cancelled and 62% of theatre hours are used. NHS England wants nobody over 52 weeks...
dfff58c7d279c452 · healthcare_waiting_list_procedure.json
An NHS acute trust in England (620 beds, 3,800 staff, a catchment of 480,000 people) has a surgical waiting list of 9,400 patients, 2,100 of them beyond 52 weeks, concentrated in orthopaedics, general surgery and ophthalmology. The list is managed as it always was: six admin coordinators build the theatre lists from each consultant's paper list, by date of referral rather than clinical need; validation (removing patients treated elsewhere, recovered or deceased) happens once a year and last removed 11% of the list; pre-operative assessment is a phone call two or three days before surgery; patients get a letter with ten days' notice and 18% ask to reschedule; 12% of theatre sessions are cancelled, 30% of them because the patient was unfit or did not attend, and 62% of the available theatre hours are used. One in five anaesthetist posts is vacant, the nursing unions oppose extended days without new hires, and NHS England requires that no patient waits more than 52 weeks within 12 months and publishes the figures monthly. Define the waiting-list management procedure: validation (frequency, criteria, who contacts patients and how), clinical prioritisation (categories, who decides, how disputes are resolved), pre-operative assessment and optimisation (when, by whom, the criteria that mark a patient ready and what happens with those who are not), scheduling (how lists are built to fill the theatre hours, notice periods, reserves for cancellations), and the weekly review that tracks the over-52-week patients — with roles, cadence, systems, and the measures that show the procedure works. |
Healthcareprocess
NHS acute trust, England
|
Words252 | Runs | Last run |
|
Duplicated invoices and wrong stock
A UK invoicing and inventory platform (outbox pattern, Kafka, Debezium to Snowflake, DynamoDB projections, a Lambda bridge to customers' ERPs) finds 0.3% of invoices duplicated (380 already paid twice by customers) and the available stock wrong by 2–5% on 1,200 SKUs after eight changes in six weeks: a scaled-out...
661fec64979cf0a5 · software_data_inconsistency_investigation_process.json
Duplicated invoices and wrong stock on an event-driven platform: define the investigationThe systemA B2B invoicing and inventory platform for wholesale distributors in the UK (2,300 customer companies, 9M invoice lines a month) runs on AWS eu-west-2 as an event-driven architecture. System of record
Events
Idempotency and time
Observability
Changes in the last six weeks
The problemTwo problems, possibly related, possibly not:
Customers are escalating; the biggest one has frozen its rollout to more branches. What has been established so farInvoices
Reporting
Stock
The team and the constraintsFive engineers, full time:
Also on the team: a finance analyst, full time, who owns the reconciliation, the list of affected invoices and customers, and the conversation with finance; and the operations lead of the fourth warehouse, on call, who knows its WMS and its counting routine. Constraints:
What you must deliverDefine the investigation process the team must follow to reach a complete diagnosis:
|
Softwareinvestigation
event-driven invoicing platform, UK
|
Words1,293 | Runs | Last run |
|
Intermittent checkout timeouts
A marketplace on AWS (42 microservices on EKS with a half-rolled-out Istio mesh, Aurora behind RDS Proxy and PgBouncer, MSK, Redis, DynamoDB) sees POST /checkout/confirm go from 450 ms to 6–14 s every weekday between 14:00 and 16:30 UTC, with 504s and payments captured without an order. Nine changes in four weeks;...
099243ac836ce293 · software_latency_investigation_process.json
Intermittent checkout timeouts on an AWS marketplace platform: define the investigationThe systemAn online marketplace for professional tools (US and Canada, 1.1M orders a month, peaks of 40 orders per second) runs on AWS in us-east-1. Edge and compute
State
Observability and delivery
Changes in the last four weeksFrom the change log, which is not necessarily complete:
The problemSince 11 days ago, on weekdays between roughly 14:00 and 16:30 UTC:
What has been established so farFour days of on-call work, no root cause:
The team and the constraintsFive engineers, full time:
Available part time: the customer-support lead, who owns the 140 tickets and can reach the affected customers, and the finance analyst who tracks the 312 orphan payments. Constraints:
What you must deliverDefine the investigation process the five engineers must follow to reach a complete diagnosis of the problem:
|
Softwareinvestigation
marketplace on AWS, US
|
Words1,245 | Runs | Last run |
No prompts match these filters.