Reducing landlord's burden of handling properties using property management web app

Role: React developer
Reducing landlord's burden of handling properties using property management web app
Client
Condexo
Country
United Kingdom
Services provided
Front-end development
Industry
Real estate
Year
2019-2021
Tech stack
Javascript, React, Redux, Redux Saga, React Bootstrap, Stripe

About the product

Condexo Property Management brought day-to-day rental management into one place for landlords, tenants, and contractors. Payments, communication, maintenance, documents, and scheduling were meant to live in a single application instead of a pile of separate tools.

This was my second project with Condexo, after shipping the MVP for Condexo Pay. I joined as a frontend developer to help build the property-management MVP. That meant turning the client's designs into React, building the product workflows, integrating APIs and payments, and helping decide how the frontend should be put together.

What we were building

The product had to work for three kinds of users on one platform. Landlords needed to manage portfolios, tenants needed to pay rent and raise requests, and contractors needed to coordinate jobs. Each group needed different things, but it still had to feel like one property management system.

The frontend team was a couple of React developers, including me, working with backend developers and a project manager. The client's in-house designer provided the screens. Their development team reviewed the work before it went to production.

Property management platformOne app for rental day to day
Landlord
Properties & tenanciesManaging the portfolio
Payments & accountsRent and accounts
Documents & schedulingFiles, calendar, and planning
Tenant
Rent paymentsPaying and tracking rent
Requests & communicationMaintenance and messaging
DocumentsContracts and files
Contractor
Jobs & scheduleAssigned jobs and timing
CommunicationUpdates with landlords and tenants
NotificationsJob and status alerts

The MVP had to cover a lot, including properties and tenancies, payments, calendar, chat, documents, and notifications. A small frontend team also needed to keep adding to it without stepping on each other. So we had to decide where to add structure, what to take off the shelf, and where custom work was actually worth it.

Engineering Decisions

For each of these, we started from a real product problem, looked at the options, and picked what fit the MVP best. If something was already a solved problem, we used an existing solution. Custom work went into the Condexo-specific workflows.

1. Structure: feature / container folders

The app was going to grow across properties, tenancies, payments, calendar, and communication. More than one frontend developer would be working at once. If everything lived in generic shared folders, related code would scatter and people would keep bumping into the same files.

How should we organise the codebase so features stay separate and developers can work in parallel without getting in each other's way?

File-type / layer folders
  • Easy to set up at the start
  • Familiar components, reducers, and sagas layout
  • Code for one feature ends up spread around
  • Shared folders become places people collide
Feature / container folders
  • Clearer feature boundaries
  • Related UI and behaviour stay together
  • Easier to own work between developers
  • Holds up better as more features land
Hybrid shared core + features
  • Shared pieces live in a common layer
  • Features still own most product behaviour
  • Needs clearer rules for what is shared
  • More to agree on before the MVP ships

We went with feature and container folders. It kept ownership clear as the product grew, which mattered more than starting with a simpler file-type layout.

2. Forms: React Forms + Yup

Landlords, tenants, and contractors all had forms. They were creating properties and tenancies, collecting details, validating them, and sending them off. If we built field state, validation, errors, and submit behaviour ourselves for every form, we would spend the MVP on plumbing instead of the product.

With so many forms and a tight MVP, how should we handle form state and validation?

Build in-house
  • Full control over how forms work
  • More work before anything ships
  • We own validation and how forms run
  • More code to keep consistent
Formik
  • Popular way to manage form state in React
  • Works well with schema validation libraries
  • Still need to choose and wire up validation
  • More to learn than we needed for MVP forms
React Final Form
  • Updates form state through subscriptions
  • Good performance story for large forms
  • Harder for the team to pick up
  • More than we needed for the MVP forms
React Forms + Yup
  • Handles form state without us building it
  • Yup schemas keep validation explicit and consistent
  • Less repeated work across many forms
  • Faster to ship with the MVP

We chose React Forms with Yup. It gave us consistent validation and less repeated form code, without us owning a form library of our own. We gave up some control. That was fine for the MVP.

3. UI: React Bootstrap + custom where needed

The UI was a mix. Tables, modals, and form layouts were ordinary. Calendar, chat, notifications, and rent payments were not. Building every component ourselves would have taken too long. Pushing the product-specific bits into a generic component kit would have made those flows worse.

How do we ship ordinary UI quickly and still build the property-specific parts properly?

Build all UI custom
  • Full control over every interaction
  • Most work before screens ship
  • We own more design and accessibility ourselves
  • Slow on ordinary screens
Material UI (full kit)
  • Large set of ready-made components
  • Good defaults for ordinary UI
  • Heavier look to adopt and override
  • Harder when a workflow needs custom behaviour
React Bootstrap + custom
  • Solid building blocks for ordinary UI
  • Lighter to take on in an MVP React app
  • Room to build calendar, chat, and similar flows
  • Clear split between reuse and custom work

We used React Bootstrap for the ordinary screens and built calendar and chat ourselves. Notifications and rent payments were treated as product features, not just styled components. We did not get a complete design system the way a full kit like Material UI would have given us. We did get faster standard screens and room to build the unusual ones.

4. Payments: Stripe

Rent and other payments sat at the centre of the product. We needed something reliable that worked in a React web app, did not put card data in our own systems, and could ship with the MVP.

How should the product take payments without us building a payments stack?

Build on bank / processor APIs
  • Full control over the payment path
  • We own more of the security and ops work
  • Longer to integrate and certify
  • Too slow for the MVP
Alternative payment provider
  • Could cover basic card payments
  • React or web SDK quality varies by provider
  • Docs and ops tools are often thinner
  • Less predictable for MVP payment flows
Stripe
  • Mature payments setup and web SDK
  • Straightforward to use from a React frontend
  • Card data stays with Stripe, not in our app
  • Quickest reliable way to take payments in the MVP

We chose Stripe. It was the strongest option for reliability, React integration, keeping card data out of our app, and shipping on time. The frontend wired payments into the rest of the product. Stripe ran the payment service.

Frontend foundation

These choices gave us a frontend with clear feature ownership, off-the-shelf pieces where they fit, and custom work where the product needed it.

React ApplicationFrontend organised by feature
Feature layer
Property managementProperty workflows
TenancyTenant and contractor workflows
PaymentsPayment-related UI and flows
Calendar / Chat / NotificationsCustom product flows
Shared foundation
ReduxShared application state
Redux SagaAsync service workflows
React Forms + YupForms and validation
React Bootstrap + StripeUI kit and payments

That was enough to grow properties, tenancies, payments, calendar, chat, and notifications without rebuilding the stack each time.

Outcome

The MVP went live in May 2020. It got the property-management product into production and helped bring more investors onto the project.

Work continued after that. Version 2.0 shipped in February 2021 with new features and a better experience as the product grew.

Testimonials

Elisa Fiorenzani
Elisa FiorenzaniUX/UI designer @ Condexo

It was a pleasure to work with Parmeet, an honest and reliable Dev!

Neha Kapur
Neha KapurProject manager @ Classic Informatics

I really enjoyed working with Parmeet. Highly recommended for React-based web development projects with the rich user interfaces. He is eager to learn and improve in all areas. He has excellent communication and technical skills. He is hard-working, ensures deadlines are duly met, and never compromises with product quality.

Naveen Dharni
Naveen DharniSenior associate @ Classic Informatics

Parmeet is an excellent developer and a great friend, he is really good in React and has been a real gem to our last company. His technical skills are impressive as per his experience. He always makes sure to meet all the deadlines within a given time frame & with the top standards. He is hardworking & dedicated in his work. It is a pleasure and honor to recommend Parmeet to anyone who wants to hire him.

Sunny Tyagi
Sunny TyagiFull stack developer @ Classic Informatics

Parmeet is a good and technical sound is his work. I worked with him on 2 projects and he developed the project proficiently on frontend and backend. I hope to get work opportunities with him in future so we can connect the world together for the betterment.

Let's bring your nextbig idea to life

Whether you're brainstorming ideas, looking to bolster capabilities, rapidly expanding your team, or delegating projects, count on us to meet your needs effectively any or every step of the way

Available for new engagements