Hire a team to build a customer portal: fixed-scope criteria for B2B ops teams

If you need to hire a team to build a customer portal, you are not shopping for a no-code widget. You run a B2B operation — regional wholesale distributor, multi-location franchise operator, or technical SaaS with enterprise buyers — where email order entry, contract pricing in spreadsheets, and “can my customer log in and see their price?” have become a revenue bottleneck. Your NetSuite Customer Center, Microsoft Dynamics 365 Business Central web client, or Epicor Prophet 21 buyer view cannot represent branch ship-to rules, account-specific price lists, or AP invoice disputes without six figures in customization.

The right build team extends your system of record. They do not rip it out. That means a React or Next.js portal front end, a Python or Node.js service layer for pricing and approval logic, PostgreSQL on AWS RDS or GCP Cloud SQL, integrations through REST APIs or EDI 850/856 via SPS Commerce or TrueCommerce, and mobile-adjacent flows on React Native when field reps need offline order capture. At Wolverine Solution (Montréal; US and EU delivery), that is the cut line: fixed-scope portal builds for ops directors, AR managers, and founders who will not fund an open-ended retainer.

If you searched wolverine software or wolverine app, this is Wolverine Solution — custom B2B portals and ops tools, not an unrelated product brand. (And no, we did not build the wolverine pc game.)

When should you hire a team instead of buying portal software off the shelf?

Hire a custom portal team when your pricing, approval, and identity rules cannot be expressed in a SaaS template — typically role-based contract pricing, ERP-sourced inventory, credit holds, lot or CoA lookup, and multi-branch ship-to logic that NetSuite, Dynamics, or Shopify B2B cannot model without heavy scripting. Off-the-shelf fits simple reorder catalogs. Custom fits ops-heavy B2B.

Most “customer portal” products assume one buyer persona, one price list, and clean SKUs. Your buyers do not work that way:

• Inside sales still retypes email POs because the portal shows list price, not contract price.
• AP contacts call about invoices that do not match what the buyer thought they ordered.
• Branch managers need ship-from rules your ERP knows but your website does not.
• Credit holds block half your accounts, and the portal has no workflow for partial release or manager override.

Buy off the shelf when you need a branded reorder form with standard catalog pricing and no ERP write-back. Hire a team when the portal must read and write against NetSuite, Epicor Prophet 21, SAP Business One, Fishbowl, Cin7 Core (DEAR), or QuickBooks Enterprise with idempotent order submission, partial failure handling, and audit trails your CFO will accept.

What should you look for in a customer portal development team?

Look for a team that has shipped ERP-adjacent portals with fixed commercial terms, named integration experience with your stack, and references from ops-heavy buyers — not only SaaS founders. They should describe credit holds, contract pricing tiers, and EDI replay behavior before you ask.

Generic dev shops sell “client dashboards.” Portal builds for B2B ops need a narrower checklist:

• System-of-record respect. They extend your ERP or accounting system — they do not propose rebuilding inventory in week one.
• Exception workflow fluency. Credit holds, Certificate of Analysis (CoA) lookup, account-specific price lists, and branch ship-to rules should appear in the discovery doc without prompting.
• Fixed-scope discipline. You budget like an operator, not a VC. Weekly demos and a written “not building” list beat T&M with no definition of done.
• Integration realism. Ask how they handle idempotent order writes, read-only vs read-write API boundaries, and what happens when EDI 856 arrives before 850 confirmation.
• Security posture. SOC 2 may be overkill at your size, but they should name OAuth 2.0, SAML SSO for enterprise buyers, row-level tenancy, and PII handling for GDPR (EU) and state privacy laws (US).
• Ops-side references. One SaaS case study is not enough. You want a buyer who stopped retyping email orders.

Red flags: “We’ll figure out the ERP integration in sprint 3,” no mention of staging vs production data, or a team that only lists WordPress + a membership plugin as portal experience.

What does a customer portal team actually build in phase one?

Phase one is usually assisted reorder or quote-to-order: authenticated buyers see contract pricing, real-time or near-real-time stock, and submit orders that land in your ERP as draft sales orders — not a full self-service ERP replacement. Ship the workflow that kills the most email. Expand later.

A disciplined first release often includes:

Capability	Why phase one	Typical stack touchpoints
Buyer login + account switcher	Multi-ship-to, parent/child accounts	Auth0, Clerk, or ERP-native SSO
Contract price display	Stops “what’s my price?” calls	Pricing service → NetSuite price levels or custom record
Stock / lead-time visibility	Reduces “is it in?” emails	Read-only inventory API or nightly sync
Order cart + submission	Cuts inside sales re-entry	Write sales order or quote via REST
Order history + invoice PDF	Deflects AP status calls	Read-only AR module or document store
Basic admin console	Your team approves exceptions	Internal React admin on same API

Defer to phase two: returns/RMA, co-op accrual reporting, complex approval chains, native mobile apps, and AI chat over order history (unless you already have clean data and eval gates).

How much does it cost to hire a team to build a customer portal?

A fixed-scope B2B customer portal with ERP read/write for one buyer persona and one order workflow starts from $12k for phase one with us, depending on integration depth, number of price rules, and whether you need EDI touchpoints. Each additional persona (AP, sales rep, branch manager) or major workflow (quotes, returns, approvals) adds scope and price.

Pricing drivers that move you up the range:

• Write-back to ERP vs read-only catalog (write-back is non-negotiable for most distributors).
• Real-time pricing vs nightly sync (real-time needs caching, fallbacks, and load testing).
• Multi-entity / multi-currency for US + EU operations.
• Custom approval graphs (credit release, margin floors, regional manager sign-off).
• Compliance artifacts — audit logs, GDPR data export, penetration test remediation.

What you should get for that money: fixed milestone payments, a written scope with explicit exclusions, weekly demos, staging environment on AWS or GCP, and handoff docs (runbooks, API diagrams, admin training). Walk away from open-ended “we’ll agile it” without a cap unless you have an internal product owner who can absorb unlimited discovery.

How do you evaluate portal teams without getting burned by the demo?

Run a paid discovery sprint (1–2 weeks, often $5,000–$12,000) before signing build work. The deliverable is a integration map, data contract, wireframes for the happy path and two exception paths, and a fixed bid for phase one — not a slide deck about “digital transformation.”

Questions to ask in the first call:

1. “Show me a portal where contract pricing came from [your ERP] — how often does it sync, and what happens when sync fails?”
2. “Walk me through a credit hold. Where is the rule stored, and what does the buyer see?”
3. “What is idempotent about your order submit endpoint?”
4. “Who owns on-call when the portal is down during month-end?”
5. “What is explicitly out of scope for phase one?”

Ask for a reference call with an ops buyer, not only the founder who loved the UI. If they cannot name REST, webhooks, PostgreSQL, and your ERP’s API limits in the same sentence, they are not your team.

What is the realistic timeline from hire to launch?

Plan 12–20 weeks for a focused phase-one portal with one ERP integration, assuming you provide API credentials, test accounts, and a single decision-maker for weekly reviews. Add 4–8 weeks if EDI testing with a trading partner or SAML SSO with a large enterprise buyer is in scope.

Typical sequence:

• Weeks 1–2: Discovery, integration map, wireframes, fixed bid.
• Weeks 3–6: API layer, auth, pricing/stock read paths, staging environment.
• Weeks 7–10: Cart, submit, order history, admin exception console.
• Weeks 11–14: UAT with 3–5 real buyers, load test, security review.
• Weeks 15–20: Soft launch, hypercare, documentation, phase-two backlog.

Slip risk is almost always data quality and ERP sandbox access, not front-end polish. Assign your IT lead or ERP admin before kickoff, not after sprint four.

What security standards should a customer portal meet?

A customer portal should use secure identity management, tenant-level data isolation, least-privilege permissions, encryption, audit logging, dependency scanning, and tested backup procedures. The exact compliance burden depends on the data involved, but every portal should be designed around OWASP guidance and verified against unauthorized cross-account access before launch.

Keep the security questions specific:

• How is one customer prevented from accessing another customer’s records?
• Does the portal support multi-factor authentication?
• Where are secrets stored?
• Which actions appear in the audit log?
• How are uploaded files validated and scanned?
• How quickly are access changes applied?
• What is backed up, and has restoration been tested?
• Which team receives production alerts?

Automated tests should try to reach records across tenant boundaries and fail. That’s worth more than the phrase “enterprise-grade security” appearing in a proposal.

Card details in scope? The architecture should shrink Payment Card Industry Data Security Standard exposure by leaning on a provider such as Stripe instead of storing payment data. Health, financial, or European personal data can pull in HIPAA, SOC 2, or General Data Protection Regulation requirements, and discovery is where you find that out.

A compliance badge is not the same as understanding the portal’s data flow. Don’t trade one for the other.

How should you measure whether the portal worked?

A portal worked if customers complete the target task with less effort and the business handles fewer manual exceptions. Establish a baseline before development, then review adoption, completion, support demand, processing time, and failure rates after launch. Traffic and login counts alone do not show whether the operational problem improved.

Pick one primary outcome, then a few guardrails.

For a returns portal:

• Primary KPI: Median time from request submission to decision
• Adoption KPI: Percentage of eligible returns submitted through the portal
• Efficiency KPI: Staff minutes spent per request
• Quality KPI: Percentage requiring manual correction
• Reliability KPI: Successful integration jobs as a percentage of attempts

Record the baseline during discovery. Check the numbers at 30, 60, and 90 days. Low adoption is usually an invitation, onboarding, or communication problem — look there before you build more features.

What should you ask before signing a development contract?

Before signing, ask how scope will be validated, who owns technical decisions, how integrations will fail safely, and what your team receives at handover. The answers should appear in the contract or scope document. Verbal assurances are difficult to enforce when timelines tighten or an external system behaves differently than expected.

Ask these questions:

1. What is the smallest complete workflow you recommend launching first?
2. Which assumptions could change the price or timeline?
3. How will you test that customers cannot access another account’s data?
4. What happens when an ERP or CRM integration is unavailable?
5. Who owns the source code, cloud account, domains, and deployment pipeline?
6. Which capabilities are explicitly excluded?
7. What evidence determines whether the build is accepted?
8. What support is included after production launch?

A capable partner answers on the spot. “We’ll work that out during development” is fine for a button placement. It is not fine for ownership, security, core workflows, or acceptance.

FAQ

Should we hire freelancers, an agency, or an in-house team to build our customer portal?

For a one-time portal with ERP integration, a fixed-scope agency or small product studio usually beats freelancers (coordination risk) and in-house hire (6+ months to recruit). Use freelancers for discrete UI polish or DevOps if your agency leads architecture. In-house makes sense after launch when you need continuous feature work and on-call ownership.

Can a customer portal connect to NetSuite, Dynamics, or Epicor without replacing them?

Yes — that is the correct pattern. The portal is a presentation and workflow layer; the ERP remains system of record for inventory, pricing master data, and invoicing. Builds fail when teams duplicate master data in the portal database instead of reading authoritative fields and caching with clear TTL and fallback behavior.

Do we need a mobile app or is a responsive web portal enough?

For most B2B buyers and AP contacts, a responsive Next.js portal is enough. Hire for React Native when field sales reps need offline order capture, barcode scanning with Zebra devices, or route-based workflows — common in wholesale distribution, not typical for SaaS customer portals.

How do we keep the portal secure for B2B accounts?

Require HTTPS, secure session handling, MFA for admin users, row-level isolation per account, rate limiting on auth endpoints, and secrets in a vault (AWS Secrets Manager, GCP Secret Manager). For enterprise buyers, offer SAML SSO. Log every pricing and order action for dispute resolution — your AR team will need it.

What should we put in the SOW when we hire a portal team?

Include: personas in scope, ERP objects read/written, sync frequency, order states, explicit exclusions, acceptance criteria per milestone, warranty/hypercare period, IP ownership, and who pays third-party fees (Auth0, cloud hosting, SPS Commerce). If it is not in the SOW, assume it is out of scope.

---

Ready to scope your portal? Wolverine Solution ships fixed-scope B2B customer portals for wholesale distributors and multi-location operators — ERP-adjacent, no open-ended retainer. Book a 30-minute scope call with your ERP, buyer volume, and the one workflow you want gone from email first.

---

Need this built? Our team does fixed-scope fixed-price portal build — scoped, priced and delivered in weeks.