INTERNAL PRODUCT & ARCHITECTURE BRIEF

Nimble Quote Builder Prototype

Product, workflow, pricing, and implementation guide

Prepared for: Internal stakeholder evaluation and pitch development

Current status: Local interactive prototype and live test url; no active Nimble connection

Prototype live test location: https://quote.pcmdigital.com

Document date: September 4, 2026

Current guardrail: The prototype is local-only. It uses three fictional contact records, does not authenticate to Nimble, does not write to Nimble, and does not send or store customer data.

Executive summary

The prototype demonstrates a practical website-quoting workflow for PCM Digital. It begins with client information, defines the website scope, assembles package and add-on pricing, and produces a polished proposal preview that can be printed or saved as a PDF. The current preview uses two pages, but the final proposal may expand to additional pages as content, font sizes, and design requirements evolve. The prototype is intentionally framework-neutral, allowing stakeholders to evaluate the workflow before choosing WordPress or React for production.

The pricing engine and proposal renderer are functional. Nimble behavior is simulated behind a clearly marked integration boundary because the actual authentication method, data objects, field mappings, API operations, permissions, and write-back requirements have not yet been approved or confirmed.

What the prototype establishes

1. A three-step internal sales workflow can gather the information needed for a representative website quote.

2. PCM website packages, copywriting options, hosting, and maintenance can be represented as maintainable configuration rather than hard-coded proposal copy.

3. Page count and project type can drive a package recommendation while still allowing a salesperson to choose another package.

4. A live, branded, two-page proposal preview can be generated entirely in the browser for architecture and pitch evaluation.

5. A dedicated connection layer can translate approved Nimble data into the format used by the quote builder. This keeps the interface and pricing calculations independent from Nimble details that have not yet been confirmed. This is not in existence as of the date of this document.

1. Purpose and boundaries

The proposed system is an internal quote-building tool for website projects. It is intended to help a salesperson or account representative move from a CRM contact to a consistent, understandable proposal without manually rebuilding scope and pricing each time.

Business goals

1. Reduce time spent gathering client details and assembling website estimates.

2. Make pricing and package logic easier to review, maintain, and approve.

3. Create a more consistent client-facing proposal format.

4. Provide a defined path for reading client information from Nimble and, if approved, recording quote outcomes back to Nimble.

5. Separate confirmed business rules from assumptions that still require product, sales, finance, security, or legal decisions.

Current implementation status

Important: This is a workflow and architecture prototype, not a production quoting system or customer-ready agreement. Pricing, proposal language, taxes, payment schedules, approval rules, data retention, and legal terms must be confirmed before production use.

Prototype file structure

2. User experience and quote workflow

The interface uses a guided three-step builder on the left and a live proposal preview on the right. Changes appear immediately in the preview, allowing a stakeholder to evaluate how data, pricing, and customer-facing language move through the experience.

End-to-end flow

1. Start from a contact. Choose a fictional Nimble record and import it into the client fields, or type client information manually.

2. Review client context. Confirm company, contact, email, website, and the primary objective for the new site. Objectives could be AI-generate and inserted.

3. Define website scope. Choose the project type, target timeline, page count, primary goals, and content readiness.

4. Select pricing. Review the automatically selected package, choose copywriting and maintenance options, and see package details.

5. Assemble the quote. The pricing engine creates one-time and recurring line items, totals, and custom-pricing caveats.

6. Review the proposal. The two-page preview updates client information, scope, deliverables, pricing, and service notes.

7. Produce an output. Use the browser print dialog to print the proposal or save it as a PDF.

Information captured

Package selection behavior

The prototype deliberately opens with the Custom Website package selected at a starting price of $5,200. This default is enforced in both the HTML and JavaScript so a browser cannot silently restore the older $999 selection. When the page count or project type changes, the system selects the package that matches the current scope. A salesperson can then manually select a different package. The Pricing-step badge always shows the current selection rather than a stale page-count label.

Recommendation rule: 1-3 pages selects the 3 Page Website; 4-5 selects the 5 Page Website; 6-10 selects the 10 Page Website; 11-15 selects the 15 Page Website; more than 15 pages or any e-commerce project selects Custom Website.

3. Pricing model represented in the prototype

The figures below reflect the pricing materials that were found in the “Product PDFs” section in Nimble. We will update this when current information has been verified. The rate source used is the PCM Website Pricing sheet dated July 2023 and the application displays a reminder to verify rates before production use.

Website packages

Add-ons and recurring services

Calculation rules

1. One-time total = selected website package + selected per-page copywriting option.

2. Monthly total = $16.99 hosting and SSL + any selected monthly maintenance plan.

3. Hourly maintenance is shown as $150/hour but is not added to the monthly subscription total.

4. Custom Websites start at $5,200. The final price is determined after reviewing the project requirements and approving the completed scope.

5. Items outside package limits - including e-commerce, additional forms or addresses, and expanded galleries - require confirmed custom pricing.

6. If the system cannot recognize a selected package or maintenance plan, it defaults to the Custom Website package with no maintenance plan to prevent incorrect pricing.

Pricing control: Before production, rates should move into an approved configuration source with effective dates, change history, permissions, and a defined approval owner. Historical quotes must retain the rate version used when they were created.

4. Representative website deliverables

The prototype uses professional, client-neutral deliverable language derived from a variety of sources regarding goals, solutions, hosting, and maintenance. These items describe a representative website engagement; the final list must be narrowed or expanded to match the selected package and approved scope.

1. Custom, brand-aligned visual design: A polished interface using the client's identity, content priorities, and approved visual direction.

2. Responsive layouts: Usable presentation across desktop computers, tablets, and mobile devices.

3. Content organization and navigation: Clear pathways to important pages and scoped search or other navigation features where required.

4. Content management: A CMS with appropriate front-end and back-end editing capabilities for authorized users. In our case, WordPress.

5. Lead generation: Secure contact forms and conversion-focused calls to action aligned with business goals.

6. Social integration: Links or integrations for existing social media profiles where included in scope.

7. SEO and analytics foundation: Basic on-page search optimization and analytics configuration.

8. Security foundation: Security hardening and website firewall protection appropriate to the production platform. We recommend a free plugin for on-site protection.

9. Licensed imagery: Professionally sourced, royalty-free or Adobe Stock imagery as needed and approved.

Hosting representation

The current prototype does not include the free hosting for the first year. The recurring hosting line is described as secure managed hosting with SSL, performance caching, and support. The prototype does not select a server, provision hosting, transfer a site, test capacity, or guarantee a hosting architecture. Final hosting responsibilities, service levels, backup retention, migration fees, and third-party dependencies still need confirmation if they lie outside our current deliverable service.

Maintenance representation

The current generic maintenance coverage describes:

1. Website platform, theme, and plugin updates.

2. Scheduled database and website-file backups.

3. Security monitoring, alerts, and routine remediation.

4. Performance and operational upkeep within the selected plan's included hours.

Routine maintenance excludes major repairs, custom development, content changes, substantial revisions, and work outside the approved plan unless those services are separately scoped. Subscription hours expire monthly and additional time is represented at $150/hour; these business rules must be reconfirmed before production.

5. Proposal preview and PDF strategy

The right side of the prototype is a live document preview. It is organized as two readable letter-style pages instead of compressing all content onto one sheet. It can be expanded.

Page structure

Current PDF behavior

1. The preview is HTML and CSS, not a separately generated PDF file.

2. The Print / Save PDF button opens the browser print dialog.

3. Print CSS hides the application controls and places each proposal sheet on a separate letter-size page.

4. Client, scope, package, add-on, maintenance, and total changes update both pages in real time.

5. The quote number is generated from the current year and day of year; it is not guaranteed to be unique across users or multiple quotes created on the same day. This can be changed.

Production PDF requirements

1. Choose a server-side PDF renderer and define supported fonts, assets, page-break behavior, and accessibility requirements. If this eventually gets implemented in Nimble, we will review what that looks like. There are several options outside of Nimble as well.

2. Generate a unique immutable quote identifier rather than relying on the date alone.

3. Store the quote input, calculated output, pricing version, PDF version, creator, timestamps, and approval state.

4. Define whether PDFs are attached to Nimble, linked from Nimble, emailed from the application, or stored in another approved system.

5. Add formal proposal terms, expiration date, taxes, payment schedule, signature/acceptance behavior, and revision rules if required.

Architecture principle: The browser may display live quote calculations and previews, but the production server must independently validate and finalize all pricing, generate the official PDF, manage storage and permissions, and handle external integrations. This prevents users from altering authoritative quote data through the front end.

6. Nimble integration boundary

Nimble is represented as an external CRM source and possible write-back destination. The prototype intentionally does not invent endpoints, authentication flows, objects, or field names. The current import contact action reads only from three JavaScript objects stored in the browser code.

Conceptual production flow

1. Authenticate the internal user. Verify that the user is allowed to search contacts, create quotes, view prices, and publish proposals.

2. Search through a server-side adapter. The browser asks the application backend; the backend calls Nimble using an approved authentication and authorization model.

3. Map confirmed CRM data. Translate approved Nimble contact/company fields into the quote builder's internal data model.

4. Calculate and save the quote. Apply a versioned pricing configuration on the server and store a snapshot of inputs and results.

5. Render and store the proposal. Create the authoritative PDF, store it in an approved location, and return a controlled link or attachment.

6. Write back only approved outcomes. Optionally record the quote status, amount, package, document link or attachment, and activity after permissions and field mappings are approved.

Known versus unresolved integration details

Do not connect yet: No Nimble connection, credential entry, data extraction, or write-back should be added until the integration scope has been approved and confirmed technical documentation and access has been provided.

7. Production architecture options

The prototype is plain HTML, CSS, and JavaScript so the team can evaluate the workflow independently of the final platform. Both WordPress and React remain viable, but both require a trusted server layer for Nimble access, authoritative pricing, PDF generation, storage, and auditing.

Option comparison

Recommended architecture principles

1. Keep the user interface, Nimble connection, pricing calculations, PDF generation, and quote storage as separate parts of the system.

2. Never expose Nimble credentials or privileged write operations directly in browser JavaScript.

3. Treat the server calculation as authoritative even when the browser provides instant preview totals.

4. Preserve the prices, calculations, deliverables, and proposal template used for each quote so historical quotes can be accurately reopened or reproduced after the system is updated.

5. Give each user only the access required for their role, and maintain a record of sensitive actions such as pricing changes, quote approvals, PDF generation, and updates sent to Nimble.

6. Make integration failures recoverable; a temporary Nimble or PDF failure should not erase quote work.

Practical selection rule

Choose WordPress if the primary goal is a protected internal tool operated by existing WordPress users with modest workflow complexity and the team wants to reuse its PHP/hosting expertise. Choose React with a dedicated backend if the quote builder is expected to become a larger application with approvals, versioning, collaboration, reusable components, more integrations, or a long independent product roadmap.

8. Validation completed

The prototype has been checked at the source and calculation level during iteration. The following validations apply to the current local build:

1. JavaScript syntax checks pass for app.js and quote-engine.js.

2. DOM selector audit passes: JavaScript references resolve to existing unique HTML IDs.

3. The HTML contains exactly one initially checked website package: Custom Website.

4. The initial pricing engine result is From $5,200 and carries the custom-quote caveat.

5. Package recommendation boundaries pass for 1-3, 4-5, 6-10, 11-15, and 16+ pages, and e-commerce selects Custom Website.

6. Monthly calculations pass for hosting combined with Economy, Deluxe, and Ultimate maintenance.

7. The two-page proposal markup and CSS structure pass static checks.

8. The downloadable ZIP archive passes integrity testing.

9. The user has reviewed the current local presentation and confirmed that it is looking good.

What has not been validated

1. No live Nimble authentication, contact search, field mapping, or write-back has been tested.

2. No production database, quote history, permissions, concurrency, or recovery behavior exists.

3. No server-side PDF generation, attachment storage, email delivery, or digital acceptance has been tested.

4. No formal browser/device compatibility matrix, accessibility certification, security review, load test, or user acceptance test has been completed.

5. Current prices and business terms have not been reapproved for production use.

9. Local operation

Expected local project location

Windows path: C:\laragon\www\quote-prototype

Required local files

1. index.html

2. styles.css

3. app.js

4. quote-engine.js

5. images\logo-pcm-digital.webp

6. images\logo-pcm-digital-black.png

Run and review

1. Copy the latest four code files into the quote-prototype directory while preserving the images folder.

2. Start Laragon and open the project through the local virtual host or localhost path configured on the PC.

3. Use Ctrl+F5 after replacing files so the browser does not display cached CSS or JavaScript.

4. Walk through Client, Scope, and Pricing; confirm the package badge, totals, and two proposal pages update.

5. Use Print / Save PDF and confirm the browser shows two letter-size pages with no application controls.

Local data behavior

The prototype does not include a backend or database. Refreshing the page resets the quote. Data typed into the form stays in browser memory for the current page session unless the user prints or saves the proposal. The fictional records use example.com addresses and should remain the default for demonstrations until a secure test-data policy is defined.

10. Decisions required before production

Suggested next phase

1. Run a short stakeholder review of the prototype and this document.

2. Lock the quoting rules, package language, add-ons, exclusions, and approval owners.

3. Document the real Nimble objects and allowed integration actions with the CRM administrator.

4. Select the production platform using the expected workflow complexity and team ownership model.

5. Build a thin vertical slice: authenticated user, real read-only CRM lookup, server-side calculation, saved quote, and server-generated PDF.

6. Perform security, accessibility, browser, calculation, and user-acceptance testing before enabling any write-back or customer use.

Appendix A. Sources and document upkeep

Source materials represented

1. Current local quote-prototype files: index.html, styles.css, app.js, and quote-engine.js.

2. PCM Website Pricing - July 2023.

3. PCM Web Maintenance pricing and service information.

4. Supplied goals, objectives, solution, web hosting, and maintenance reference pages.

Document status: This brief describes the current prototype and is intentionally editable. Update it alongside pricing, scope language, architecture decisions, and integration findings so it remains the single working explanation of the system.

Keep this brief current

1. Update the document date and current-status statement whenever a materially different prototype version is adopted.

2. Replace July 2023 pricing only after the new rate source and effective date have been approved.

3. Move Nimble details from unresolved to confirmed only when the CRM owner supplies authoritative field, authentication, and permission information.

4. Record the selected production architecture and remove the unused option once the decision is approved.

5. Update the validation section after each major implementation or integration milestone.

6. Replace prototype disclaimers with approved proposal, privacy, security, and legal language before customer use.