Case study · Real estate technology

MaverickRE: keeping a real estate sales platform moving forward

MaverickRE builds sales analytics software for real estate teams. Widle worked as an extension of their engineering team, looking after existing features, fixing bugs, building new requirements and writing tests across a stack that runs from Retool and React to Python, PostgreSQL, MySQL, GraphQL and AI integrations.

Talk about a project like thisWhat we built

The challenge

What wasn’t working

MaverickRE’s product helps real estate team leaders keep on top of their leads and their agents, so it has to stay reliable while new features ship.

It needed engineers who could take on the day-to-day work: keeping existing features healthy, fixing issues quickly and turning new requirements into shipped features.

Every change also needed tests, so the platform could grow without breaking what customers already rely on.

The solution

What we built

Feature maintenance

Looking after existing features so they keep working as the product and its data grow.

Bug fixing

Finding and fixing issues wherever they show up, from the Retool and React screens to the Python services and databases.

New features

Turning new requirements into shipped features in the existing codebase.

Retool and React screens

Building and updating screens in Retool and React as new requirements come in.

Data, APIs and sign-in

Work across PostgreSQL, MySQL and GraphQL, with OAuth handling sign-in, so every screen pulls the right data for the right user.

Python and AI integrations

Python services and AI integrations maintained and extended alongside the rest of the platform, with tests for every change.

How it works

How we worked with the MaverickRE team

  1. 1

    Requirement or issue

    A new requirement or a reported bug comes in from the MaverickRE team.

  2. 2

    Build or fix

    We make the change wherever it belongs: Retool, React, Python, the databases or the AI integrations.

  3. 3

    Test it

    We add or update automated tests alongside the change.

  4. 4

    Ship it

    The change goes out, and existing features keep working as before.

The result

What changed

  • An engineering team that knew the codebase and handled the day-to-day work
  • Existing features kept healthy while new ones shipped
  • Changes tested before they shipped, across the whole stack

More work

More case studies

All case studies →
Parking technology

Oparko: customer and admin apps for a Danish parking platform

Read the case study →Short-term rental management

Houst: Retool apps that run property operations for a short-term rental company

Read the case study →Sports clubs (SaaS)

Xaver Sports: a SaaS platform and Retool back office for multi-sport clubs

Read the case study →

Have a project like this?

Tell us what you need to build. In 30 minutes we’ll map what to build first and follow up with a fixed-scope estimate.

Official Retool Agency Partner5.0 on Clutch, 8 verified reviewsBuilding software since 2015Reply within one business day

Book a free 30-minute callContact us