Suriwaize

• 

  house checked showing 3D result

Suriwaize — AI building-permit checks for Suriname Inspiration Getting a building permit is slow everywhere, but the frustrating part is why it is slow: on one side, architects spend days cross-checking their drawings against building regulations instead of designing. On the other side, civil servants spend their days re-doing that same check by hand instead of helping citizens. Two groups of professionals, both stuck doing the one part of their job a machine is genuinely better at. I had already built a working version of this idea for the Surinames market (suriwaize, a live SaaS for architects): https://suriwaize.vercel.app/ . That gave me a conviction: the checking itself is not the valuable part of either job. The valuable part is the architect's creativity and the civil servant's care for the citizen. This submission is the architect side: check your plan before you submit it, so it arrives at the government desk already compliant. I am currently rebuilding it into a civil-servant version for the intake side — same engine, two lenses on the same problem. What it does An architect uploads a PDF floor plan, and optionally the standards book it must comply with. The AI reads the actual drawings — dimensions, rooms, openings, annotations — and produces a structured compliance report: every requirement is scored as compliant, partially compliant, non-compliant, or not demonstrable, with a priority level (critical / important / cosmetic) and a concrete explanation of what to fix. The plan can also be explored as an interactive 3D model generated from the 2D drawing. The reason this matters is simple math. Permit turnaround is roughly $$T_{\text{permit}} \approx (1 + r) \cdot (T_{\text{queue}} + T_{\text{review}})$$ where $r$ is the expected number of rejection-and-resubmission rounds. Every round restarts the queue. A pre-check that pushes $r \to 0$ doesn't just save the review time — it collapses the whole loop. That's the same reason the civil-servant version is the natural second half: it attacks $T_{\text{review}}$ directly. How I built it The app is a Next.js 16 / React 19 / TypeScript application with a PostgreSQL database (Drizzle ORM on Supabase) and S3-compatible storage — plans are uploaded straight from the browser via presigned URLs, so drawings never pass through my server unnecessarily. The AI layer is built on the Vercel AI SDK . The key design decision: the model is never allowed to answer in free text. Every verification must conform to a strict Zod schema — statuses, priorities, evidence, per-requirement check items — which the app then flattens into database rows and renders as a report. If the output doesn't validate, it doesn't ship. Because the standards book is an input rather than hardcoded logic, the same engine that checked Dutch regulations can check Surinamese ones — that's what made the Suriname rebuild feasible for one person: I'm swapping the rulebook and the audience, not rewriting the brain. The rest is production plumbing that a real tool needs: authentication with email verification, per-user projects and documents, AI cost tracking per transaction, caching of expensive AI steps so the same drawing is never analyzed twice, and a test suite (Vitest + Playwright) that gates every deploy. Challenges I ran into Making AI output trustworthy enough for a legal-adjacent domain. A compliance report you can't rely on is worse than no report. The answer was structure and honesty: forcing schema-validated output, and — most importantly — giving the model an explicit "not demonstrable" verdict. The most dangerous failure mode of an LLM is confidently guessing; giving it a legitimate way to say "the drawing doesn't show this" removed most hallucinated verdicts. Reading drawings, not documents. Floor plans are not text. Scale bars, dimension lines, symbols, and overlapping annotations are hard even for multimodal models. I learned to test different providers per document type, cache aggressively, and treat every AI feature as unproven until it survived real plans — not demo plans. Keeping a live product stable while transforming it. This isn't a weekend prototype; the Dutch original has paying users and is fully GDPR compliant). Every change had to be additive and verified — reproduce the problem first, fix it, prove the fix against the reproduction, then deploy. As a solo builder, that discipline is the only thing standing between me and breaking someone's workday. Adapting to a different market. Suriname isn't the Netherlands with different colors. Pricing models, digitization level, language needs, and how government offices actually work all differ. Rebuilding meant stripping assumptions (like subscription billing) out of the product, not just re-skinning it. What I learned The value of AI in professional workflows isn't the clever answer — it's structured, verifiable, boring output. Schemas beat prose. An honest "I can't tell" from the model is a feature, not a weakness. If you make the rules an input instead of code, one engine can serve many countries. Solving one side of a two-sided process is only half a product. The architect and the civil servant are looking at the same document; software should let them stop fighting over it. What's next for Suriwaize The civil-servant version: an intake view where a government official sees the same verified report the architect saw, checks what the AI flagged instead of re-checking everything, and spends the recovered hours on the citizens waiting at the counter. After that: Surinamese standards content built out with local experts, and hosting close to the users it serves. Check a project on https://suriwaize.vercel.app/project/34daae8c-f884-4089-9600-1be72c4878e6 User ID: demo@suriwaize.sr Password: demo1234

Built With

• amazon-web-services
• analytics
• css-framework:-next.js-16-(app-router)-with-react-19;-tailwind-css-v4
• drizzle-orm
• google-oauth
• jotai
• next.js
• openai
• postgresql
• radix-ui
• react
• react-email
• resend
• resend-+-react-email-for-verification-mails-pdf-handling:-pdf.js-for-reading-plans
• shadcn-ui
• shadcn/ui-and-radix-ui-for-the-interface;-motion-for-animations;-jotai-for-state;-next-intl-for-multi-language-support-ai:-vercel-ai-sdk-with-multi-provider-routing-to-openai-gpt
• sql
• supabase
• typescript
• validated-verification-output-database-&-storage:-postgresql-on-supabase-with-drizzle-orm;-supabase-s3-compatible-storage-with-presigned-browser-uploads-for-the-pdf-plans-auth-&-email:-better-auth-(email/password-+-google-oauth)
• vercel
• vitest
• zod