Revolutionizing Home Design: An AI-Powered House Planning Platform

Building a home is one of the biggest decisions most families ever make — and one of the most opaque. Professional architectural services are expensive and out of reach for a lot of people, especially in the affordable-housing segment. So for our final-year B.Tech capstone at APJ Abdul Kalam Technological University, my team set out to answer a simple question: what if you could describe your budget, your plot, and how your family lives — and get a real, optimized house design back?

That became Revolutionizing Home Design, a full-stack, AI-powered house planning and visualization platform. This post is the complete story of it — the problem, the architecture, the machine learning, the parts that fought us, and what a year of building it taught me about shipping applied AI end to end.

Why this problem, and why it's personal

If you've grown up in Kerala, you've watched families build homes the hard way. It is one of the most significant financial acts a household undertakes — often the single largest — and it is astonishing how little of it is legible to the people paying for it. A family will commit their savings, and often years of future income, to a process where the final cost is genuinely unknown until they're deep into construction and it's far too late to change course.

We kept coming back to three specific pain points, because every family we talked to had lived at least one of them.

• Cost is unpredictable. Most people don't know what their house will actually cost until the money is already spent. Estimates given up front are frequently optimistic, and the gap between the quote and the reality is where dreams get quietly downsized halfway through.
• Good design is gated. Architects and quality planning aren't accessible to everyone, particularly for low- and middle-income families. The people who would benefit most from thoughtful spatial planning are precisely the ones priced out of it.
• Finding trustworthy people is hard. Architects, contractors, skilled workers, and material suppliers are scattered across word-of-mouth networks, and quality is a gamble. A bad contractor can turn a sound budget into a half-finished house.

We wanted one platform that bridges all three — from the very first idea a family has, all the way to the people who actually pour the concrete. Not a design tool, not a marketplace, not a calculator, but the connective tissue between them. That ambition is what made it a real engineering problem instead of a class project.

What it does

You enter your plot dimensions, budget, room count, family needs, and design preferences. From there the platform handles the rest:

• AI-generated floor plans optimized to your spatial constraints
• ML-driven cost estimation so you know the realistic price up front
• A building-material recommendation engine matched to budget and use
• Energy-efficient & sustainable design suggestions
• Government housing-subsidy guidance to support affordable housing
• A verified marketplace of architects, contractors, workers, and suppliers
• Real-time messaging between homeowners and providers
• An AI chatbot for design assistance along the way

The critical design principle behind all of it: meet the user where they are. A family does not think in square footage and load-bearing walls. They think "three bedrooms, space for my parents to visit, a kitchen my wife actually wants to cook in, and please keep it under this number." The entire platform is an exercise in translating that human language into engineering constraints and back again.

How it's built

The platform spans a web app, a mobile app, and an ML/AI backend:

• Backend & AI — Python, with machine-learning models for cost estimation and natural-language processing (Hugging Face) powering the design assistant.
• Mobile — Flutter / Dart for a cross-platform app.
• Web — a responsive dashboard (Bootstrap) for onboarding and management.
• Data — MySQL.

My role spanned architecture, the backend, and the AI modules — wiring the design-generation and cost-estimation pipelines into the product and shaping how the web, mobile, and ML pieces talk to each other. In practice that meant I owned the seams: the contracts between the ML services and the app, the data model everything shared, and the decisions about what ran where.

Let me walk through the architecture the way I think about it — as a set of layers, each with a clear job.

The data layer

Everything rests on a relational model in MySQL. This was a deliberate choice over something more fashionable: the domain is inherently relational. A user has projects; a project has a plot, a budget, generated designs, and cost estimates; the marketplace has providers with verifications, specializations, and message threads tied back to projects. When your domain is this connected, fighting a relational database is a losing game. We leaned into it — well-normalized tables, foreign keys that actually enforce the relationships, and a schema that made the illegal states hard to represent.

I drew the core schema on paper before writing a line of it, and I'm glad I did. The shape of these entities — what a Project is, how a Design relates to a CostEstimate, where a provider's Verification lives — is the decision every other layer inherits. Getting it right early saved us from the special kind of pain where a wrong data model forces awkward code everywhere forever.

The AI/ML layer

This is the layer that made the project interesting, and it's really three distinct systems wearing one trench coat.

Floor-plan generation takes the plot dimensions and spatial constraints and produces a layout that respects them — room adjacencies that make sense (kitchen near dining, bathrooms clustered for plumbing economy), circulation that works, and proportions that fit the actual plot rather than an idealized rectangle. The hard part is that "a good floor plan" is a soft constraint satisfaction problem dressed up as a creative one. There are hard rules you cannot violate (the house must fit the plot; a bedroom needs a door), and soft preferences you're optimizing against (morning light in the kitchen, the parents' room away from the noise).

Cost estimation is where the machine learning earns its place. Rule-of-thumb per-square-foot numbers are how the industry lies to itself; real cost depends on the materials, the finishes, the labor rates, the region, and dozens of interacting choices. We trained models to predict realistic cost from the design and material selections, so the number a family sees up front is grounded in something better than a hopeful guess.

The design assistant uses NLP (via Hugging Face models) to let users describe what they want conversationally and get useful guidance back. This is the piece that turns "a tight budget but I want it to feel open" into concrete, actionable suggestions rather than a shrug.

The application layer

The Flutter mobile app and the Bootstrap web dashboard are the two faces of the same system. Mobile is where a homeowner lives day to day — browsing designs, chatting with providers, checking their project. The web dashboard handles the heavier onboarding and management flows and the provider side of the marketplace. Both talk to the same Python backend over a shared API, which is exactly why nailing that API contract early mattered so much: two clients, one source of truth, no drift.

Why the AI matters here

The interesting part wasn't bolting an LLM onto a form. It was turning fuzzy, human inputs — "a 3-bedroom home for a family of five on a tight budget, with room to grow" — into concrete, constrained outputs: a floor plan that respects the plot, a cost estimate grounded in real material prices, and material choices that balance budget against durability and sustainability. That's a chain of models and rules working together, not a single prompt.

And that chain is the whole thesis of the project. A single model that tries to do everything produces plausible mush. What works is a pipeline: natural-language understanding to parse intent, a constrained generator for the layout, a trained regressor for cost, a recommendation engine for materials, each doing one thing well and handing off to the next with a clean, checkable interface between them. It's the same instinct I bring to any system — small pieces with clear contracts beat one monolith that's clever everywhere and reliable nowhere.

A closer look at floor-plan generation

Of everything we built, floor-plan generation is the piece people ask about most, so it deserves a proper explanation. The naive framing — "an AI draws a house" — hides what's actually going on, which is a constraint-satisfaction problem with an aesthetic objective bolted on top.

Start with the hard constraints, the ones you cannot ever violate. The total built area must fit within the plot, accounting for setbacks and boundaries. Every requested room must exist. Rooms need doors; a bedroom you can't enter is not a bedroom. Wet areas — kitchens and bathrooms — want to be clustered so that plumbing runs are short and cheap, because plumbing that snakes across a house is money spent on nothing the family can see. Structural walls need to line up floor to floor. These are non-negotiable, and a layout that breaks any of them is simply invalid, no matter how pretty.

Then come the soft constraints — the preferences you optimize toward but can trade off against each other. Morning light in the kitchen and dining area. The primary bedroom positioned away from street noise. The living space flowing naturally from the entrance. Room proportions that feel generous rather than boxy. Circulation — the hallways and paths through the house — kept minimal, because every square foot of corridor is a square foot the family paid for and can't live in.

The engineering challenge is that these two categories pull against each other and against the plot. A layout that maximizes morning light might waste space; a layout that minimizes circulation might dump you straight into a bedroom from the front door. Our approach treated it as exactly what it is — an optimization over valid layouts, scoring candidates against the soft preferences while hard constraints acted as a filter that threw out the invalid ones entirely. The output that reaches the family is one that satisfies everything it must and does as well as it can on everything it should.

What made this genuinely hard, and genuinely interesting, is that "good" here is partly subjective and culturally specific. A layout that reads as ideal in one context feels wrong in another — the role of a central courtyard, the placement of the kitchen, the importance of a formal sitting area for guests versus casual family space. Encoding even a fraction of that domain sensibility, rather than producing generic boxes, is what separated a layout a family might actually build from a shape that merely fit the plot.

A closer look at cost estimation

If floor-plan generation is the feature people find impressive, cost estimation is the feature that makes the platform trustworthy — and trust was the entire point. A beautiful design with a fantasy price tag is worse than useless; it sets a family up for exactly the mid-construction heartbreak we were trying to prevent.

The industry's default is the per-square-foot rule of thumb, and it's close to useless for a specific family's specific house. Two homes of identical area can differ enormously in cost depending on the number of floors, the finishes, the materials, the complexity of the structure, and the labor rates where it's being built. A flat multiplier averages all of that away and hands you a number that's precise-looking and frequently wrong.

So we treated cost as a prediction problem. The features that feed the model are the things that actually drive cost: built-up area, floor count, room composition, the materials selected, the class of finishes, and regional factors. The model learns the relationships between those inputs and real outcomes, which lets it produce an estimate that responds to the actual design rather than a smoothed-over average of every house ever built.

The honest hard part, again, was data. A model that predicts cost is only as trustworthy as the examples it learned from, and assembling realistic, structured cost data for the domain was the single largest sink of effort in the whole subsystem. Cleaning it, validating it, deciding what to do about the gaps and the outliers — this was the unglamorous work that actually determined whether the feature could be trusted. It's a lesson I've never unlearned: in applied machine learning, the model architecture is rarely the thing that decides success. The data is.

We were also careful about how we presented the number. A single point estimate implies a false precision, and false precision is how you rebuild the exact overconfidence we were fighting. Framing cost as a grounded, honest figure — with the sense that it's an informed prediction rather than a guarantee — mattered as much as the model behind it. The goal was never to be magically exact. It was to be dramatically more honest than the status quo, which promised certainty it never had.

A closer look at the design assistant

The NLP-powered design assistant is where the platform felt least like a form and most like talking to someone who knew what they were doing. Families don't arrive with specifications; they arrive with feelings and constraints tangled together — "something modern but not cold," "open but private," "room for the kids to grow into." The assistant's job was to meet that language honestly and turn it into guidance.

Built on Hugging Face models, it parsed conversational input and mapped it toward the concrete levers the rest of the platform understood — room counts, spatial priorities, material and finish preferences, budget sensibilities. The value wasn't in sounding clever; it was in being the bridge between how a family naturally describes their dream and the structured inputs the generation and estimation pipelines needed. A good assistant answer moved the user one real step closer to a design, every time.

Designing it also taught me an early, durable lesson about applied language models: the model is a component, not the product. On its own it produces fluent text; wired into a pipeline with clear inputs and outputs, and grounded against the platform's actual data and constraints, it becomes genuinely useful. The engineering was in the wiring and the grounding, not in the model call. That's a principle I now apply to every LLM feature I build.

The mobile app, and why Flutter

We chose Flutter for the mobile app for a reason that has only looked smarter with time: it let a small student team ship one codebase to both Android and iOS without maintaining two. For a capstone with fixed hours and a lot of surface area to cover, that leverage was decisive. But beyond the practical calculus, building the app in Flutter and Dart is where I first fell for cross-platform mobile as a discipline — the single-codebase model, the reactive UI, the tight feedback loop of hot reload. That experience carried directly into work I've done since, and it's a big part of why I consider mobile a first-class part of my stack rather than an afterthought bolted onto web skills.

The app is where the homeowner actually lives inside the product — browsing generated designs, reviewing cost estimates, exploring material recommendations, and messaging providers. Which meant the interesting mobile engineering wasn't the widgets; it was state and data. Keeping a design, its estimate, its materials, and its conversation threads coherent as the user moves between screens is a real state-management problem, and getting it wrong shows up immediately as stale or inconsistent data that erodes exactly the trust the whole platform depends on. Doing it right on mobile taught me things about disciplined state management that I still lean on today.

The material recommendation engine

This is a subsystem I'm quietly proud of, because it's where the platform's values show up in code. Recommending building materials isn't just "cheapest that fits." A good recommendation balances upfront cost against durability (a cheap material that fails in five years is expensive), against sustainability (we wanted to nudge toward energy-efficient, environmentally sounder choices), and against the actual use of the space. A material that's perfect for a bedroom wall is wrong for a wet area.

Encoding that meant capturing real domain knowledge — properties of materials, their costs, their appropriate uses — and matching it against the family's budget and the specific spaces in their design. The output isn't just a shopping list; it's a set of justified choices a family can understand and adjust. Making the reasoning legible, not just the answer, was a recurring theme across the whole platform.

Designing for sustainability, not as an afterthought

Energy-efficient and sustainable design suggestions were on our feature list from the start, and I want to be clear that this wasn't greenwashing bolted on to sound responsible. In a warm, humid climate like Kerala's, the difference between a home that's designed with orientation, ventilation, and materials in mind and one that isn't is the difference between a house you can live in comfortably and one that fights the weather with electricity every single day. Sustainability here isn't abstract virtue; it's lower bills and better living for the family, for the life of the house.

So the platform's suggestions leaned toward choices that reduce a home's energy demand — orientation that works with the light and heat rather than against it, materials and layouts that favor natural ventilation, finishes chosen with thermal behavior in mind. The nudge was always framed in terms the family cares about: comfort and long-term cost, with the environmental benefit as the thing that comes along for free. That's the version of sustainability I believe in as an engineer — not lecturing users, but designing the responsible choice to also be the one that obviously serves them. When doing right by the planet and doing right by the person point in the same direction, you don't have to convince anyone of anything.

Subsidy guidance and the affordable-housing mission

One feature that mattered to us more than it might sound: government housing-subsidy guidance. There are real schemes designed to support affordable housing, and there is real friction between those schemes and the families who qualify for them — awareness, paperwork, eligibility that's hard to parse. Building guidance for this into the platform was a direct expression of the mission. It's not enough to make good design cheaper to plan; if we could also help families access the support they're entitled to, the platform did more of what we actually set out to do. Affordable housing was never a marketing line for us. It was the point.

The verified marketplace and real-time messaging

A design a family loves is worthless if they can't find someone trustworthy to build it. So the platform includes a verified marketplace of architects, contractors, skilled workers, and material suppliers — with verification being the operative word. Anyone can list a directory of names; the value is in the trust layer on top.

Tied to that is real-time messaging between homeowners and providers, so a conversation about a project can happen in context, attached to the actual design and requirements rather than lost in a WhatsApp thread. Connecting the messaging to the project data — so a contractor is discussing this plan, this budget, these materials — is what turns a chat feature into a genuinely useful part of the pipeline from idea to built house.

Building it as a team of four

This was not a solo project, and pretending otherwise would erase one of the most valuable parts of the experience. Four of us built it, and coordinating a system with this many moving parts across a team taught me as much about engineering as any single technical problem did.

The instinct on a student team is to slice the work by person — you take mobile, you take the models, I'll take the backend — and then discover at integration time that the slices don't fit, because everyone made quietly incompatible assumptions at the boundaries. We avoided the worst of that by treating the interfaces between our pieces as shared, explicit contracts rather than private details. If the mobile app and the backend agreed on exactly what a design object looked like, we could build our halves in parallel and trust they'd meet in the middle. The contract was the coordination.

That's a lesson that transferred directly into professional work. On the Sipo platform today, the same principle holds at larger scale: clear contracts between systems are what let people work independently without stepping on each other. I learned it first here, on a capstone, by feeling the pain of the times we got it wrong and the relief of the times we got it right. The technical skills from this project matter, but the instinct for how to decompose a big system so a team can actually build it in parallel might be the most professionally useful thing I took away.

There's also something clarifying about building alongside people who are all invested in the same outcome. Decisions got pressure-tested in conversation before they became code. A design one of us was sure about would meet a good objection from another and come out better for it. That's the same dynamic I now deliberately recreate with AI agents in my daily workflow — different perspectives catching different problems — but I felt it first the human way, with three teammates who cared as much as I did.

The parts that fought us

No honest engineering write-up skips the hard parts, so here are the ones that taught us the most.

Data was the constant battle. Machine learning is only as good as what you train it on, and realistic cost and material data for the domain isn't handed to you in a tidy CSV. A large share of the effort went into assembling, cleaning, and structuring data good enough to train models we'd trust to show a family a number they'd make decisions on. This is the unglamorous truth of applied ML that no tutorial prepares you for: the modeling is the easy 20%.

Constraints are harder than creativity. Generating a floor plan is easy. Generating one that respects the plot, satisfies room requirements, keeps circulation sane, and still feels like a home someone would want to live in — that's a genuinely hard constrained-generation problem, and it's where we spent real time balancing hard rules against soft preferences.

Integration is where projects go to die. Three clients (mobile, web) over a Python backend and an ML layer, all needing to agree on the shape of the data — this is exactly the kind of seam where an under-planned project quietly falls apart. The fact that it didn't comes down to defining the contracts between the layers early and treating them as the real product. The models and the screens were replaceable; the interfaces between them were the architecture.

How do you even test a system like this?

A question that stumped us early and that I still think is underrated: how do you test software whose outputs are supposed to vary? A traditional app has deterministic behavior — given input X, assert output Y. A platform that generates floor plans and predicts costs doesn't work that way. There's no single correct floor plan to assert against.

We ended up thinking in terms of properties rather than exact outputs. A generated floor plan is correct if it satisfies every hard constraint — fits the plot, includes every requested room, has valid circulation — regardless of which specific valid layout it landed on. So the tests we trusted checked those invariants: does the output fit? Are all rooms present? Is every space reachable? You can't assert the plan is the "right" one, but you can assert it's never an invalid one, and that turns out to be most of what matters for safety.

For cost estimation, evaluation looked more like classic ML — holding out data and measuring how far predictions landed from reality, then asking whether the error was small enough to be genuinely useful to a family making a decision. And for the qualitative pieces — did a floor plan actually feel like a home, was a material recommendation sensible — there was no substitute for human judgment. We looked at outputs, a lot of them, and built intuition for where the system was strong and where it needed guardrails. Learning to evaluate non-deterministic, partly-subjective systems rigorously is a skill I've carried into every AI feature I've touched since; it's a fundamentally different muscle from asserting expect(x).toBe(y), and most engineers never get to build it.

What "verified" actually meant

I keep using the word verified about the marketplace, and it's worth being honest about what a student team could realistically deliver there, because the gap between the aspiration and the implementation is itself a lesson. The vision was a trust layer strong enough that a family could pick a contractor from the platform and feel safe. The reality is that real-world trust is enormously hard — it involves credentials, history, reviews, dispute resolution, and accountability that go far beyond what any capstone builds in a semester.

What we built was the structure for trust: verification status on providers, specializations, the connection of every provider to real project conversations rather than anonymous listings. What a production version would need is the hard operational layer on top — the actual verification process, the reputation system, the recourse when things go wrong. Naming that gap honestly, rather than pretending we'd solved trust, is part of engineering maturity. You ship the structure you can, you're clear about what's scaffolding versus what's load-bearing, and you don't oversell it. That honesty about the boundary of what you've actually built is, I think, as important a professional skill as the building itself.

The bigger vision

Step back from the individual features and the thing we were really chasing was legibility — making one of life's most opaque, high-stakes processes understandable to the people living through it. Every feature was a translation: fuzzy human intent into concrete design, hidden costs into an honest number up front, a scattered and untrustworthy market into a connected and accountable one, bureaucratic subsidy schemes into plain guidance. The unifying idea wasn't "AI for houses." It was giving families information and agency in a process that has historically denied them both.

That framing is why the project has stuck with me. The best software doesn't just automate a task; it shifts power toward the person using it. A family that walks in with a budget and walks out with a realistic design, an honest cost, a set of justified material choices, and a line to trustworthy builders is a family that has more control over the biggest financial decision of their lives. That's the kind of impact that made the long nights feel worth it, and it's the bar I try to hold my work to now.

What I'd do differently

With the perspective of everything I've built since, a few things stand out. I'd version the ML model interfaces from day one, the way I now version any API — the model outputs are an API, and treating them casually made a few refactors more painful than they needed to be. I'd invest even earlier in the data pipeline, because every hour spent there paid for itself several times over in model quality. And I'd push harder on making every AI output explainable to the user from the start, because the moments where the platform showed its reasoning were the moments families actually trusted it.

None of these are regrets, exactly. They're the difference between how you build your first end-to-end applied-AI system and how you'd build your second — which is precisely the value of having built the first.

Recognition

The work was accepted and presented at the International Conference on Cognitive Informatics, Engineering & Technology 2026, organized by Vidyaa Vikas College of Engineering & Technology (Autonomous) in collaboration with OSIET, Chennai and Samarkand State University, Uzbekistan (Tiruchengode, Tamil Nadu — 28–29 March 2026).

If you want the full detail, here's the project report and the presentation slides.

Team

Built with Gopika Gireesh N G, Rinsha Ashraf, and Sayanth K, submitted in partial fulfillment of the B.Tech in Computer Science & Engineering at Vimal Jyothi Engineering College, Chemperi (Kannur).

What it taught me

Looking back, this is the project that taught me the most about shipping something end-to-end — the data model, the ML pipeline, the mobile app, the web dashboard, and the messy human problem sitting in the middle of all of it. Class projects usually let you get away with one strong layer and a lot of hand-waving around the rest. This one didn't. To make it work, every layer had to actually function and, harder still, had to function together.

That experience is the through-line to everything I do now as a software engineer. Whether it's the Sipo Cloud POS platforms I build for restaurants across New Zealand, or personal products like FinPlanner and OnSite Tracker, the instinct is the same: own the whole stack, respect the seams between the pieces, and never lose sight of the human on the other end who just wants the thing to work. This capstone is where that instinct was forged.

If you're working on applied-AI products and want to compare notes — especially on the unglamorous data and integration problems that decide whether these systems actually ship — reach out. I love talking about this stuff.