Trapped by their own systems. Not anymore.
Industry
Manufacturing
Company size
50 - 200 Employees
About
Architectural window systems in Australia encompass highly engineered aluminium glazing solutions tailored for residential and commercial applications. They focus on energy efficiency, thermal performance, and compliance with strict Australian building codes.
Halcrow changed the relationship completely. They embedded directly into our infrastructure from day one — not at arm's length, not through a ticketing system, inside it. Decisions that would have taken weeks happened in a single meeting. Issues that would have cost thousands were fixed the same day.
97.3%
Product data accuracy up from 73% under old CMS
4.7 per week
Marketing team content publishing updates up from 0.3 under old CMS
We've been inside enough initiatives to know where the value actually is and where businesses waste on technology.
Book Your Diagnostic Call
The Situation
AWS Australia (Architectural Window Systems) manufactures high-end windows and sliding doors. Architects specify their products in project designs. Fabricators source materials to exact specifications. The website and data systems feed this entire chain—from architect specification through to fabricator ordering.
By mid-2024, AWS Australia had a problem. Their previous agency, had built them a custom monolithic Content Management System years earlier. The system worked—until it didn't. Every change request came with eye-watering quotes. The architecture was fragile. Technical audits revealed critical issues, but pushing fixes live risked breaking the entire platform. The team knew bug patches existed but couldn't deploy them. The system had become a liability masquerading as infrastructure.
Angela (National Marketing Manager, Economic Buyer) needed out. Not a bandaid. Full escape velocity from vendor lock-in.
Key Result Metric (KMR): Digital transformation maturity—specifically, data accuracy delivered to fabricators and architects. If product specifications, AutoCAD files, or technical drawings were wrong or inaccessible, projects stalled. Fabricators ordered incorrect materials. Architects couldn't specify with confidence. The old CMS created downstream chaos AWS Australia could measure in lost orders.
Why they called us
They didn't call us to "refresh the website." They called us because they'd diagnosed the structural problem themselves and needed someone who could operate differently.
What made this a recovery project:
The previous agency relationship had collapsed under three Laws:
Law 1 (Structural Distance): The previous partner operated at arm's length. Specs were thrown over walls. Custom-built meant "call us for every change, we'll quote it, then schedule it three months out."
Law 2 (Requirements Quicksand): Requirements were written as high-level wishlists. "We should have X." No user types, no priority, no success criteria. Conversations looped endlessly on "keep everything vs simplify" without decisions. The IA had years of accumulated baggage—duplicate pages, overlapping categories, unclear boundaries between the public website and the fabricator/specifier systems.
Law 7 (Integration Theatre): The monolithic CMS was theoretically "integrated"—but in reality, it was a black box. Nobody could add features. Nobody could fix bugs without risking cascading failures. Integration meant dependency, not capability.
AWS Australia had agency fatigue. Every request felt like negotiating with a vendor who owned the keys to their house.
How we worked
We didn't pitch "rebuild your CMS." We embedded ourselves as an extension of their product team across three vectors:
Technical Embedding
From day one, we operated inside their infrastructure:
JIRA project setup (AWS key, arcadedevhouse.atlassian.net)
Direct server access (Micron21 UAT environment)
1Password shared vault (AWS CMS, AWS Specify, AWS Connect)
WordPress + Kontainer PIM administrative access
No "send us a ticket" theatre. We didn't request access to fix things—we had access to fix things. Issues went from report → fix → deploy in the same day when needed.
Decision-Making Embedding
Every Monday: sprint planning with Angela, Yousif (Product Owner), and Saif (Execution Lead). Every Friday: review and retrospective. Decisions that would have taken the previous agency three weeks of "we'll get back to you" happened in-meeting.
Example from July 2024: The team was stuck on "what do we do with MyProjects feature?"—a fabricator tool with unclear usage data. In the old model, this would have been a month of emails. We ran a 30-minute usage audit in the meeting. Answer: keep it, but make it public. Decision made. Work tickets created. Moved on.
Product Embedding
We structured commercial terms with 12.5% of fees in outcome-based bonuses tied to the KMR:
PIM implementation completion with data accuracy >95%
Fabricator portal integration with <5% error rate on specifications
Architect portal with CAD file download success >98%
Website-to-PIM sync latency <24 hours
If data wasn't accurate, we didn't get paid in full. If systems didn't integrate cleanly, we ate the cost. This wasn't altruism — it was shared downside. When problems surfaced, there was no "not our scope" because our bonus depended on solving them.
Build Structure: Staged Escape Velocity
Phase 1: PIM Procurement & Foundation (July–August 2024)
The escape route required choosing a modern PIM to replace the monolithic CMS's product data management.
Law 10 (Avoid Multi-Front Wars): We didn't try to rebuild everything simultaneously. First, get the central nervous system right—the Product Information Management layer. Then rebuild portals and website as clients of that system.
Week 1-2 (July 5-12, 2024): Kontainer hierarchy V1 locked in Week 3 (July 12-17): Vendor due diligence (Kontainer, SalesLayer, PIMCore, Akeneo, Plytix) Week 4-6 (July 19-August 5): UAT group testing (3 personas: marketing specialist, fabricator, architect) Week 7-8 (August 5-12): Kontainer V2 based on feedback Week 9 (August 12-15): Training workshops
Critical decision point: Angela pushed to move fast. Some vendors offered "enterprise" solutions with 6-month implementations. We chose Kontainer because their API was developer-friendly, implementation could happen in 12 days instead of 12 weeks, and the team could learn it in a week. Speed mattered—every month on the old CMS was a month of expensive change requests and fragile infrastructure.
Phase 2: WordPress CMS Rebuild (August–September 2024)
Law 9 (Incremental Exposure Reduction): We didn't do a "big bang" cutover. WordPress V1 went live as a parallel system first—public-facing content migrated, but fabricator/architect portals stayed on old infrastructure temporarily.
August 15-September 16: WordPress V1 deployment
Elementor-based frontend (practical constraints, not perfect, but workable)
Content audit and IA simplification: removed duplicate pages, clarified boundaries between public website vs. Kontainer-owned fabricator/specifier flows
Wireframes → high-fidelity designs → build in 4-week cycles
The WordPress choice was deliberate: maintainable, massive plugin ecosystem, AWS's marketing team could edit content without calling us for quotes. The previous partner's custom CMS required developer intervention for every comma change. WordPress meant operational independence.
Phase 3: Portal Integration & Data Sync (September 2024–May 2026)
This is where most "rebuild" projects fail—the integration layer. Old systems don't die cleanly. Data doesn't migrate itself. Users resist new workflows.
We tackled this with monthly maintenance cycles (JIRA evidence: 9 months of consistent monthly iteration from August 2025 to May 2026):
August–October 2025:
Multi-select conversions with data migration (custom field types from old CMS → Kontainer schema)
Product hero image optimization (architects needed high-res, fabricators needed fast load times)
Solution overview pages (product categories needed landing pages with clear CTAs)
November 2025–January 2026:
WordPress/PIM sync service with CDN integration (24-hour latency target)
Project listing order changes (fabricators sorted by proximity, architects by project type)
PDF download features (technical spec sheets generated from PIM data)
February–May 2026:
Revit file → ZIP package replacement (architects wanted entire spec packages, not individual files)
Folder access configuration (permissions by user role: fabricator vs. architect vs. internal)
Backend category creation workflows (AWS marketing could add product categories without developer intervention)
UI responsiveness fixes (mobile usage was 40%+ from architects on job sites)
This wasn't "scope creep"—it was continuous product evolution within the outcome-aligned commercial structure. Each iteration closed gaps between what the system could do and what users needed to do their jobs.
Law Applied: Law 8 (Capability Transfer). Success wasn't "we built it." Success was "they can run it without us." By May 2026, Angela's team was adding products, editing pages, and managing users without opening tickets. Operational independence achieved.
WHAT CHANGED
System Performance (May 2026 vs. June 2024):
Product data accuracy: 97.3% (up from 73% under old CMS)
Fabricator specification error rate: 2.1% (down from 18%)
Architect CAD download success: 99.1% (up from 81%)
Content update time: <5 minutes (down from 2-3 weeks via previous partner)
Operational Metrics:
Time-to-fix for issues: 3.2 days avg (down from 4-6 weeks)
Marketing team content publishing: 4.7 updates per week (up from 0.3 under old CMS)
Change request cost: $0 (down from $3,500-$12,000 per request with previous partner)
Business Impact:
Fabricator reorder rate: +34% (easier access to past specs)
Architect specification time: -67% (10 minutes vs. 30 minutes)
AWS marketing team operational independence: 100% (zero developer tickets needed for routine content)
Qualitative Shifts
Before: "We can't make that change, it'll cost $8,000 and take 3 months." After: "Let me update that this afternoon."
Before: "We found a critical bug, but deploying the fix might break everything." After: "Bug fixed, tested in staging, deployed to production, monitoring for 24 hours."
Before: "We need to schedule a meeting with the agency to discuss adding a product category." After: "I added three new product categories this morning. Want to review them?"
The psychological shift was bigger than the technical one. AWS Australia went from learned helplessness (trapped by vendor lock-in) to operational agency (we own our systems, we make changes when needed).
WHY THIS WORKED
Most recovery projects fail because they repeat the structural problems that caused the original failure.
Company hires Agency A. Agency A builds custom system. Company becomes dependent. Agency A charges premium for changes. Company gets frustrated, fires Agency A, hires Agency B.
Agency B says "we'll rebuild it better!" But Agency B operates the same way: arm's length, change requests, scope boundaries, billable hours. The structure hasn't changed. Only the vendor name.
AWS Australia broke the pattern by changing the relationship structure:
Embedded vs. Arm's Length: We operated inside their infrastructure, not outside it.
Outcome-Aligned vs. Time-Billed: Bonuses tied to data accuracy, not hours worked.
Capability Transfer vs. Dependency Creation: Training and documentation baked in, not add-ons.
Laws Demonstrated
Law 1 (Structural Distance Creates Friction): The previous partner operated at arm's length. Every change was a negotiation. We embedded directly—issues went from report to fix in the same day.
Law 3 (Direct Infrastructure Access Eliminates Translation Layers): We had admin access to WordPress, Kontainer, AWS servers. No "submit a ticket" overhead. Configuration → test → deploy cycles measured in hours.
Law 5 (Shared Downside Eliminates Misalignment): Outcome-based bonuses meant: if data accuracy failed, we didn't get paid. No finger-pointing, no scope games. Fix it or lose the bonus.
Law 9 (Incremental Exposure Reduction Prevents Catastrophic Failure): We didn't do a "big bang" migration. WordPress launched first for public content. Portals migrated incrementally. Each step was reversible. No "we're committed now, hope it works" moments.
Law 11 (Outcome-Defined Success Prevents Feature Bloat): KMR was data accuracy, not "number of features shipped." We said no to features that didn't move the metric. Old agency would have said yes (more billable hours). We optimized for impact, not activity.
what you're buying
What You're Buying
If your organisation is trapped in vendor lock-in—paying premium rates for basic changes, unable to iterate without multi-month lead times, stuck with fragile custom systems—you're not buying "technical debt cleanup." You're buying operational independence.
Most agencies optimise for looking busy. Halcrow optimises for moving metrics. If systems break, we fix them (no "call support" overhead). If requirements change mid-project, we adapt (no change request theatre).
You're not buying our time. You're buying escape velocity from vendor dependency.
Ready to break free? Contact Sam Halcrow on 0431197004 or sam@halcrow.com.au
Case study written May 2026. AWS Australia is a real client. Kontainer, WordPress, and WalterWakefield are real vendors/agencies. All data sourced from JIRA project records and Notion documentation. Metrics verified by client stakeholders.
See how other teams are winning with Halcrow
Growing fast. Flying blind. Not anymore.
Metric #1
Metric #1 description
Read more
