Highlights
- Platform: Existing product, proposed AI upgrade.
- Ownership: Clear integration responsibilities.
- Data: Readiness shapes implementation.
- Validation: Staging feedback guides next steps.
Highlights

How Mediusware helped turn a model prototype into a defined integration plan- with clear responsibilities, data dependencies, and a client review milestone.
Client, individual, and partner names have been withheld for confidentiality.
The sustainability model had reached the proof-of-concept stage. Connecting it to a property platform was the next challenge.
An external AI partner had developed a prototype that classified listings by sustainability category. The client wanted to explore how those predictions could appear within an existing application developed by Mediusware.
That required decisions beyond the model itself: how the application would request predictions, where it would store them, how listing cards would communicate them, and who would evaluate the experience.
The development discussion established a specific direction: use an API connection, assign implementation responsibilities, and demonstrate the first phase on a testing site for broker and selected-client feedback.
This case study examines that planning milestone and the platform work that preceded it.
The platform’s original ambition was to help homeowners move from property information toward practical improvement decisions.
The intended journey would let a homeowner begin with a listing or property details, explore sustainability guidance, consider approximate improvement costs, and find professional support.
Mediusware’s project account describes work across product definition, interface design, full-stack engineering, property-data integration, and cloud deployment. Supplied project visuals illustrate desktop and mobile search experiences, sustainability-related entry points and a chatbot interface.
The product direction connected 4 homeowner questions:
Indicative pricing was intended to support comparison and planning. Confirmed quotations remained the responsibility of the relevant contractor or specialist.
The existing platform provided the starting point for the proposed predictive AI upgrade.
The external partner’s prototype used a snapshot of the platform’s property data to classify listings into 3 categories:
A second proposed feature would compare a property’s expected price tier with its listed price and potentially display a position label on the listing card.
These capabilities were distinct from the existing chatbot. Conversational assistance offered an interaction channel; the predictive model would generate a classification from property features.
For the product team, the next task was to connect that output to a recognizable workflow. A prediction needed a place in the application, an understandable meaning, and a review process.

The integration discussion separated model provision from application implementation.
| Participant | Responsibility defined in the plan |
| External AI partner | Supply the model endpoint and establish the client’s account |
| Mediusware | Connect the backend, store predictions, and prototype their presentation within listings |
| Client’s product lead | Review the first phase with a broker and selected clients, then guide adjustments. |
Mediusware’s proposed contribution covered the application work surrounding the model: connecting to its endpoint, retaining returned predictions, and presenting them within the property experience.
The client would then assess whether that combined workflow was useful enough to develop further.
The participants aligned on an API route rather than an MCP-based approach for the initial integration.
The meeting account records the selected approach without documenting a detailed performance, security, or cost comparison. The immediate planning outcome was a defined connection between the model provider and the existing application.
| Stage | Intended behavior |
| Model access | Use the external partner’s endpoint. |
| Backend integration | Connect the existing platform to that endpoint. |
| Prediction storage | Retain the returned classification in the application |
| Listing presentation | Prototype how the prediction appears to users. |
| Client review | Demonstrate the combined workflow on a testing site |
Broader dataset uploads and retraining were discussed as possible later steps, outside the initial connection scope.
This sequencing established an initial body of work for estimation, implementation, and review.
The client’s product lead requested a first phase on a testing site, followed by a demonstration to a broker and selected clients.
That review would address a question beyond technical model performance: does the prediction help someone using the property platform?
A sustainability label needs interpretation. A user should understand what it represents and how it relates to the property being viewed.
The proposed price-position label introduced a similar presentation challenge. Its wording needed to communicate the intended comparison without overstating what the model could establish.
A staging demonstration would bring the backend connection and listing interface together for review. Feedback could then inform adjustments before the work expanded.
For that review, recommended acceptance checks would include:
These are editorial recommendations for evaluating the proposed workflow, not documented project commitments.
The model depended on property records containing usable information.
An earlier review had identified missing listing data. Mediusware regained environment access, but the available account does not establish a subsequent resolution of the underlying issue.
The model discussion also identified missing features in some sold-property records. Adding more records would therefore not automatically make more listings suitable for classification.
The recorded issues concerned 2 dependencies:
| Dependency | Question for the integration |
| Availability | Can the platform retrieve the required listings? |
| Complete | Do those records contain the features the model needs? |
Alongside those recorded issues, classifier evaluation raises a further planning question: are suitable labeled examples available to assess its predictions?
These questions concern different parts of readiness. The application needs accessible listings, the model needs relevant inputs, and the evaluation needs an appropriate comparison set.
Treating them separately makes the next development milestone easier to define and inspect.

The discussion translated a broad request for predictive AI into a specific integration direction.
It established an API route, assigned application responsibilities to Mediusware and identified staging feedback as the next validation step. Property-data availability and completeness remained dependencies requiring attention.
The supplied material supports the following status summary:
| Area | Supported status |
| Existing platform | Reported as built by Mediusware in the project account |
| Search and chatbot interfaces | Illustrated in supplied project visuals |
| Sustainability classifier | Proof of concept reported by the external AI partner |
| Backend connection, prediction storage, and listing UI | Proposed Mediusware integration scope |
| Broker and selected-client review | Requested validation milestone |
Completion boundary: The available records do not confirm a completed API integration, accepted staging demonstration, production release, or measured business improvement. The outcome described here is the integration-planning milestone.
An existing application and a promising model still leave important implementation questions unanswered.
This engagement made those questions concrete: identify the endpoint, assign backend and interface responsibilities, examine data dependencies, and establish who would review the combined experience.
For founders and CTOs, that creates a practical basis for discussing scope and acceptance. Each proposed capability can be connected to an implementation task and a condition for review.
In this project, the proposed capability would classify listings by sustainability category. Integrating it required backend connectivity, prediction storage and an interface that communicated the output.
