This section addresses the RFP requirements and outlines our commercial approach.
See About Newism.
The project team includes:
See Team.
Urban List itself is our primary reference. We have partnered with Urban List for over ten years, delivering the current platform and supporting its evolution through multiple phases of growth. This proposal builds directly on that relationship and the retained knowledge it represents.
See Work that matters for case studies of relevant projects.
The RFP describes an ambitious platform with broad scope. Some requirements are well-defined; others will need clarification. The requirements are not yet prioritised, which makes line-by-line costing impractical without more information.
We can deliver on all aspects of the RFP. To do so effectively, we start with discovery to understand priorities and define requirements precisely before committing to a detailed build estimate.
Purpose:
Outputs:
| Deliverable | Description |
|---|---|
| Prioritised requirements (MoSCoW) | All RFP requirements categorised by priority |
| User stories | Key functionality defined as user stories |
| Technical flow charts and state diagrams | How key systems work: search, content taxonomy, membership sign-up and billing |
| Content model | Entity relationships and taxonomy structure (some prototyped during discovery) |
| Sitemap and information architecture | Site structure and navigation model |
| Integration specifications | CDP/CEP, advertising, membership requirements |
| Analytics event plan | Tracking requirements and reporting structure |
| Refined project budget | Based on agreed priorities |
| Risk and dependency register | Identified risks with mitigation approaches |
| Performance benchmarks | Agreed Core Web Vitals targets and acceptance criteria |
| Handover requirements | Documentation, training, and acceptance criteria for sign-off |
These deliverables form the brief for development. They are reference documentation throughout the build, not throwaway artefacts.
Discovery is fixed-price because both parties benefit from shared understanding before committing to a larger engagement.
Understanding MoSCoW prioritisation
MoSCoW is a simple framework for deciding what gets built first. It stands for Must, Should, Could, and Won't:
| Priority | What it means |
|---|---|
| Must have | Essential for launch. The platform cannot go live without this. |
| Should have | Important, but launch is possible without it. Can be deferred if needed. |
| Could have | Nice to have. Stretch goals if we are ahead of schedule. |
| Won't have (this phase) | Out of scope for now. Documented for future planning. |
This framework protects the budget. If we hit roadblocks, lower-priority items can be deferred to keep the project on track. If we are ahead of schedule, we tackle stretch goals within the same envelope.
We have prepared an initial WIP MoSCoW prioritisation based on the RFP. This represents our interpretation and should be validated during discovery.
Approximately 40% of build time
De-risk the project before designing something that might not be achievable.
We tackle technical challenges first:
We prototype in-browser with real content rather than static mockups. This saves time and ensures outcomes are achievable in the real platform.
If something is going to be difficult or impossible, we find out now.
Approximately 60% of build time
Design with confidence. The hard problems are solved; the data model is stable.
Designers work with a functioning platform:
This phase also includes:
Design work is grounded in what the platform can actually do, not assumptions that need to be walked back later.
Feedback cycles run constantly throughout both phases. We do not disappear for weeks and return with an incorrect implementation. Regular check-ins keep everyone aligned and allow course correction before problems compound.
Formal acceptance against agreed requirements and performance benchmarks defined in discovery. Platform handover includes documentation and training as specified.
Following acceptance:
We want to deliver maximum value for your investment. MoSCoW prioritisation makes this possible by focusing effort on what matters most.
This approach protects both parties:
The result is predictable cost with maximum value.
| Phase | Duration | Hours | Investment |
|---|---|---|---|
| Discovery | 2 weeks | 80hrs | $12,000 (fixed) |
| Build (prototype, design, development) | 8-12 weeks | 480hrs-640hrs | $72,000-$96,000 |
| Total | 10-14 weeks | 560hrs-720hrs | $84,000-$108,000 |
The build estimate is a range because RFP requirements are not yet prioritised or fully defined.
Discovery produces:
After discovery, we confirm the build budget based on agreed scope. The MoSCoW framework ensures we deliver core functionality within budget, with flexibility to adjust priorities as the project progresses.
The following are outside the core estimate unless explicitly agreed:
This proposal is based on the following assumptions:
Large platform projects carry inherent risks. The following are the most common sources of delay or cost overrun:
Risk: Requirements that appear straightforward in the RFP turn out to be more complex when examined in detail.
Mitigation: Discovery phase to validate requirements before committing to detailed estimates. Prioritisation framework to ensure core functionality is protected.
Risk: Delays in stakeholder review extend the project timeline and increase cost.
Mitigation: Scheduled review cycles with clear ownership. Progressive approval rather than single sign-off gates.
Risk: Business priorities shift during delivery, requiring scope changes.
Mitigation: Iterative delivery allows priorities to shift between phases. Changes within a phase are managed through the prioritisation framework. Significant changes are discussed openly and re-estimated.
Risk: Third-party integrations (CDP/CEP, advertising, payment) introduce delays or require unexpected work.
Mitigation: Integration-ready architecture. Clear boundaries between Newism's responsibility (hooks and data layer) and third-party vendor responsibility (platform configuration).
Risk: Legacy content has inconsistencies or data quality issues that complicate migration.
Mitigation: Newism has deep familiarity with the existing database. The working demo includes a comprehensive migration that validates the approach. Content audit using analytics data identifies high-value content for prioritisation.
| Phase | Duration |
|---|---|
| Discovery | 2 weeks |
| Build (Phase 2 & 3) | 8-12 weeks |
| Sign-off & Acceptance | 1-2 weeks |
| Total | 11-16 weeks |
Example: Starting 1 April 2026, go-live would be mid-June to mid-July 2026.
Target go-live window will be confirmed following discovery, based on agreed scope and priorities.
Head of Marketing - easyauto123 / Eagers Automotive
Newism has delivered multiple campaigns for us, always under tight commercial deadlines. They've built a lead generation system that integrates directly with our sales CRM, handling complex routing across 500 dealerships. Even when brand guidelines shifted mid-project, they adapted quickly and kept us on track. The results speak for themselves — measurable conversions that matter to the business.
Website Optimisation Lead - Hunter Water
A trusted partner for more than six years, consistently delivering tailored solutions through Craft CMS to meet our customers’ needs.
Marketing Specialist - The PHN
As a marketing specialist at the PHN, working with Newism has been an exceptional experience. Their team is fantastic at navigating complex web development challenges with a clear and efficient process, ensuring that every project runs smoothly from start to finish. Their customer service is second to none, always responsive and proactive in addressing our needs. Beyond technical expertise, Newism brings a strategic mindset to problem-solving, helping us craft solutions that align with our goals. They’re a team you can trust, and I can’t recommend them highly enough.
Group Digital Marketing Manager - Wests Newcastle
Our digital projects span everything from the visually rich Anchorage Port Stephens website, where brand presentation was paramount, through to our membership platform managing 50,000+ members at scale. Newism understands that different projects have different priorities — sometimes it's about creating a stunning visual experience, other times it's about robust systems that handle complex member management and integrations. They've delivered on both.
