A land-and-build sales platform for a property developer
Four surfaces for a property developer selling land and house packages: a REST API, a web app, an admin panel and a Flutter mobile app.
- Sector
- Real estate
- Engagement
- November 2022 – February 2023
- Node.js
- Express
- MongoDB
- React
- Flutter
- Socket.IO
- AWS S3
Context
A property developer sells two things that a general listings site handles badly: parcels of land, and the house designs that can be built on them. The two are priced separately, browsed separately, and combined at the point a buyer enquires — so a floor plan is not a photograph attached to a listing, it is an item with its own inclusions, its own plan variants and its own enquiry trail.
The requirement was a platform the developer's own team could run: publish land and build packages, take enquiries against either, and manage the partner and content records around them, across a browser and a phone. This is sales and enquiry for a developer. It is not tenancy, facilities or property management, and the data behind it does not pretend otherwise.
What we built
REST API
A Node and Express service on MongoDB, carrying 21 route modules against 23 data models — the single source both front ends and the mobile app read from.
Web app
The public-facing browse-and-enquire surface, with a sitemap generator committed alongside it — search visibility was part of the build, not a later retrofit.
Admin panel
The developer's own back office for listings, enquiries, partners and site content, built on a purchased commercial admin theme rather than a bespoke design system.
Mobile app
A Flutter application structured into configuration, controller, repository, screen and widget layers, giving buyers the same browse-and-enquire path on a phone.
Architecture
Two payment providers are wired into the API rather than one. That is an unusual thing to find in a four-month build and it is the clearest signal in the repository of a business selling across more than one market, since each provider settles in a different one.
A realtime channel runs through both the API and the web app, sitting alongside the request-response API rather than replacing it — the pattern you get when enquiries need to reach a sales desk while the buyer is still on the page.
Media is offloaded to object storage at upload time rather than served from the application host, which is what keeps a listings product with heavy imagery from turning its API into a file server.
The admin panel is a commercial theme with the developer's modules built into it. That was the right call for a back office nobody outside the company sees, and it is the reason this study makes no claim about interface design.
Stack
- API
- Node.js
- Express 4
- MongoDB via Mongoose 6
- JSON Web Tokens
- bcrypt password hashing
- Socket.IO 4
- Payments
- Stripe
- Razorpay
- Web and admin
- React
- Formik and Yup form validation
- Socket.IO client
- Mobile
- Flutter
- Dart
- GetX state management
- Infrastructure
- AWS S3 object storage
- Multer S3 uploads
- Nodemailer
Scale
Counts that can be re-derived from the same repositories. Nothing here is a business result — a repository cannot evidence one.
- Four delivered surfaces: API, web app, admin panel, mobile app.
- 21 route modules and 23 data models in the API.
- 405 commits across the four repositories.
- Two payment providers integrated in the same service.
Where the evidence stops
- The admin panel is built on a purchased commercial theme, so nothing here evidences original interface design work.
- The engagement ran for roughly three and a half months. It is a focused build, not a multi-year platform relationship.
- No business result is recorded in the repositories, so none is claimed on this page.
Evidence
Each statement above, and the artefact it was read from. The client cannot be named, so the sources are given instead.
Four surfaces were delivered, all of them real code.
SourceRepository trees for the four surface repositories. The mobile app's Flutter project lives on the `master` branch — its `main` branch holds only a README, which understates the surface count if read alone.
The API carries 21 route modules and 23 data models.
SourceDirectory listing of the API repository's `routes/` and `models/` folders.
Two payment providers are integrated in the same API.
SourceAPI `package.json` dependencies: `stripe@^10.16.0` and `razorpay@^2.8.3`.
A realtime channel spans the API and the web app.
Source`socket.io@^4.5.3` in the API `package.json`; `socket.io-client@^4.5.3` in the web app `package.json`.
Media is stored in object storage rather than on the app host.
SourceAPI `package.json` dependencies: `aws-sdk@^2.1089.0` and `multer-s3`.
Search visibility was in build scope.
SourceA committed `sitemap-generator.js` at the root of the web app repository.
The admin panel is a purchased commercial theme, not a bespoke build.
SourceA vendor theme directory (`src/_metronic/`) in the admin panel repository tree.
405 commits across the four repositories.
SourceSum of `history.totalCount` on each repository's default branch, GitHub GraphQL API.
Related capability