Engagement at a glance
Client
Foxter
MARKET
Spanish-speaking
STATUS
Completed
DURATION
2–3 months
PROJECT OWNER
Inboundsys
THE RESULT
A new distance-based pricing model was introduced while the customer-facing website and dependent systems remained fully compatible and continuously available.
Business need: add new pricing combinations that could be managed through the existing dashboard.
Core constraint: an undocumented legacy platform and a PostgreSQL view that had reached technical limits.
Engineering response: reverse-engineer the architecture, split the oversized view, and recombine it into a final view with the exact same output structure.
Business impact: broader pricing options, lower operational risk, improved maintainability, and a scalable base for future enhancements
Executive summary
Foxter operates a car-rental business in a Spanish-speaking market. Its internal platform, built with Angular, Node.js, and PostgreSQL, manages fleet information, rental pricing, and rate combinations. Customers, meanwhile, browse vehicles and pricing through a HubSpot-based website. The two environments are operationally interdependent: backend changes must continue to feed the website in precisely the structure it expects.
Foxter wanted to add a new distance-based pricing option to support growth and make rate changes easier to manage. The request appeared straightforward, but the underlying system was undocumented, the company had no in-house technical team, and the central PostgreSQL view had reached database limitations. A poorly controlled change could have interrupted pricing visibility, damaged the browsing experience, or disrupted live rental operations.
Inboundsys approached the engagement as a controlled modernization, not a quick patch. The team mapped processes, reverse-engineered data flows and dependencies, redesigned the database-view architecture, preserved the original output contract, integrated the new logic with the HubSpot website, and supported testing, go-live, and post-launch stabilization.
WHY THIS MATTERED
Foxter gained new commercial flexibility without replacing its platform, taking the website offline, or requiring an internal technical team to absorb the complexity.
Client context
| Dimension | Project context |
|---|---|
| Business | Car-rental company serving a Spanish-speaking market. |
| Customer experience | Vehicle availability and pricing presented through a HubSpot-based website. |
| Internal platform | Angular dashboard, Node.js application logic, and PostgreSQL data architecture. |
| Internal capability | No in-house technical team; Foxter relied on external support for maintenance and enhancement. |
| HubSpot scope | Content Hub plus Data Hub / Operations Hub; Operations and IT functions covered. |
| Project profile | Completed in 1–3 months; primary HubSpot edition and approximate user count were not provided. |
The challenge: growth blocked by hidden complexity
Foxter’s immediate requirement was a new distance-based rate combination. The deeper challenge was introducing it safely into a system whose behavior, dependencies, and data contracts were not documented. The existing PostgreSQL view was already at its technical limit, so the new pricing tier could not simply be appended using the established approach.
Three interconnected risks
01 ARCHITECTURE
- No reliable documentation existed to show how the dashboard, Node.js logic, PostgreSQL views, and HubSpot website interacted.
02 DATABASE
- The oversized PostgreSQL view had reached a limitation, preventing a straightforward extension of the pricing model.
03 PRODUCTION
- Changing the output structure could break the live website or downstream systems, affecting pricing visibility and customer experience.
What Foxter wanted to achieve
Support business growth by introducing additional pricing options.
Make the new rate combination manageable through the existing dashboard.
Reduce manual intervention whenever pricing rules changed.
Keep the live HubSpot website and all dependent functionality working as before.
Create an architecture that could accommodate future enhancements without major rework.
System landscape
The solution had to preserve a continuous data path from internal rate management to the public customer experience. In practical terms, every layer remained important:
Figure 1. The customer-facing HubSpot experience depends on stable output from the internal Angular, Node.js, and PostgreSQL stack.
The Inboundsys solution
Inboundsys preserved the system’s external behavior while changing the internal database design. This compatibility-first principle allowed Foxter to gain new functionality without forcing simultaneous rewrites across the application and website.
1. Discovery and process mapping
Conducted discovery workshops to understand business rules, existing pricing combinations, and desired distance-based logic
Mapped the operational process from dashboard entry through backend processing to website presentation.
Documented the roles of Angular, Node.js, PostgreSQL, and HubSpot within the end-to-end flow.
2. Reverse engineering the undocumented platform
Traced data structures, queries, dependencies, and expected outputs because no reliable technical documentation was available.
Identified the oversized PostgreSQL view as the central scalability bottleneck.
Established which fields and structures the live HubSpot website and other dependent systems required.
3. Database-view redesign
Rather than altering the public data contract, the team split the oversized database view into two separate views. Those views were then recombined into a final view that produced the exact same output structure as before, now with support for the new pricing option.
| Existing constraint | Engineering intervention | Compatibility outcome |
|---|---|---|
| Single oversized view at its database limit | Two focused views recombined into one final view | Same expected output structure, extended pricing capability |
4. HubSpot integration and custom configuration
Connected the customer-facing HubSpot website to the backend PostgreSQL and Node.js systems so vehicles and pricing combinations could continue to display dynamically.
Preserved the existing data structure while enabling the new pricing option.
Used custom properties as the principal HubSpot deliverable identified in the project brief.
Covered Content Hub and Data Hub / Operations Hub needs across Operations and IT.
How the redesigned pricing view works
The original database view carried too much responsibility in a single structure and could not accept the additional pricing tier. Inboundsys separated the logic into two focused views so each could handle a manageable portion of the pricing model. A final view then recombined those results and exposed the same columns, field order, and expected structure to the Node.js application and HubSpot website.
This pattern created an internal seam for change while protecting the external interface. The dashboard could manage the new rate combination, the backend could process it, and the website could render it dynamically, without requiring the consuming layers to understand that the database design had changed.
Separation of concerns made the database logic easier to reason about and maintain.
Recombination preserved compatibility with the existing application and web experience.
The additional pricing option became part of the established operational flow.
Future extensions now have a clearer architectural pattern to follow.
Delivery approach
The work followed a staged path designed to reduce uncertainty before production change. It combined business discovery with architecture, configuration, integration development, testing, and operational support.
Figure 2. A controlled delivery path from discovery to post-launch support.
Activities completed
| Activity | Purpose in this engagement |
|---|---|
| Discovery workshops | Clarify commercial goals, pricing behavior, constraints, and operational expectations. |
| Process mapping | Create a reliable picture of system and data dependencies. |
| Solution architecture | Design the database-view strategy and compatibility safeguards. |
| Configuration | Prepare HubSpot properties and related platform behavior. |
| Integration development | Connect the revised backend logic to dynamic website output. |
| Testing | Validate data, pricing combinations, website behavior, and regressions. |
| Go-live support | Manage production release with continuity as the priority. |
| Post-launch support | Monitor stability and support the completed implementation. |
Risk controls built into the work
Compatibility before convenience: the final database output remained unchanged for consuming systems.
Dependency-led engineering: implementation decisions followed verified data flows rather than assumptions.
Production continuity: testing and go-live support focused on preventing website and rental-operation disruption.
No unnecessary migration: the project did not include data migration, avoiding added movement and reconciliation risk.
Validation focus
Testing concentrated on the complete commercial journey rather than the database change in isolation. The team verified that pricing data could be managed, processed, returned in the expected structure, and displayed to customers while existing functionality continued to operate. Go-live and post-launch support extended that validation into the production environment.
Results and business impact
The project achieved its primary purpose: Foxter introduced a new pricing model without downtime or adverse impact on the live website or existing business systems. Just as importantly, Inboundsys converted an opaque technical dependency into a more understandable and maintainable architecture.
0
reported downtime
1
new pricing model enabled
100%
output compatibility retained
Business outcomes
| Outcome | Long-term value |
|---|---|
| Commercial flexibility | Foxter can offer distance-based rental pricing and expand its pricing portfolio. |
| Lower manual effort | The new rate combination can be managed through the dashboard instead of relying on repeated manual intervention. |
| Reduced operational risk | The live website and dependent systems continued to receive the structure they expected. |
| Improved maintainability | The redesigned database views provide a clearer, more manageable foundation than the oversized legacy view. |
| Scalable foundation | Future pricing enhancements can be approached without an immediate platform replacement or major rework. |
| External expertise without internal overhead | Foxter gained a technically robust result despite having no in-house technical team. |
MEASUREMENT NOTE
The source questionnaire states that exact performance metrics are not available. Accordingly, this case study reports confirmed implementation outcomes and avoids unsupported estimates. No client testimonial was supplied.
Why this project stands out
Mission-critical enhancement delivered inside a live, undocumented legacy environment.
A hard PostgreSQL limitation solved through practical database engineering.
New business functionality introduced without changing the interface relied on by HubSpot and downstream systems.
No client-side technical team or documentation was required to make the engagement successful.
A risk-managed approach that balanced modernization with operational continuity.
Technical summary
| Category | Confirmed project detail |
|---|---|
| HubSpot hubs | Content Hub; Data Hub / Operations Hub |
| Departments | Operations; IT |
| Primary HubSpot deliverable | Custom properties |
| Integration | Yes, customer-facing HubSpot website integrated with PostgreSQL and Node.js backend systems |
| Data migration | No |
| Technology stack | HubSpot CMS, PostgreSQL, Node.js, Angular, and custom database architecture |
| Users and training | Approximate user count, training-session count, and users trained were not provided |
| Project status and duration | Completed; 2–3 months |
Lessons for similar integration projects
Map before modifying: When documentation is absent, dataflow and dependency mapping is a delivery task, not optional preparation.
Preserve contracts at system boundaries: A stable final output can protect customer-facing systems while internal architecture is improved.
Treat database limits as architecture signals: Splitting responsibilities across focused views can restore extensibility without forcing a platform replacement.
Test the business journey, not only the code: Pricing correctness, vehicle visibility, dashboard management, and website continuity must be validated together.
Design today’s change for tomorrow’s extension: The best implementation resolves the immediate need while reducing the cost and risk of the next enhancement.
Conclusion
Foxter’s pricing request required much more than adding a new field or rule. It required understanding a live platform with no documentation, working around a database limitation, and protecting an operationally important HubSpot experience. Inboundsys delivered that combination successfully.
By reverse-engineering the architecture, splitting and recombining the PostgreSQL views, and preserving the exact output expected by consuming systems, the team enabled distance-based pricing without downtime. Foxter now has a more maintainable and scalable foundation for growth, delivered without a major replacement program or dependence on an internal technical team.
PROJECT TAKEAWAY
Modernization does not always require rebuilding everything. With disciplined discovery, compatibility-led architecture, and production-focused testing, a legacy system can gain new capabilities while the customer experience remains uninterrupted.
A practical blueprint for similar projects
The Foxter engagement offers a repeatable approach for organizations whose customer-facing HubSpot experience depends on older or poorly documented operational systems. The first priority is to establish facts: map the process, trace dependencies, identify the true system boundary, and document the output that consuming applications expect. Only then should the internal design be changed.
The second priority is to separate modernization from disruption. If a stable interface can be preserved, internal components may be reorganized without forcing a chain of simultaneous changes across the dashboard, application layer, database, and website. This reduces the number of moving parts at go-live and gives testing a clear compatibility target.
Define the business rule and acceptance criteria before choosing a technical pattern.
Treat undocumented dependencies as risks to be investigated and recorded.
Protect the data contract used by HubSpot and other downstream consumers.
Validate existing journeys alongside the new functionality, not after it.
Carry architectural knowledge forward so the next enhancement begins with documentation, not rediscovery.
For Foxter, this method delivered the immediate pricing capability and reduced the uncertainty surrounding future change. That combination, commercial value today and safer extensibility tomorrow, is the central measure of a successful custom integration.
