OBI PASCAL BANJUARE
Backend Engineer | Node.js, NestJS, TypeScript & AWS
- 3
- Followers
So today, I was going through our product, SabiMoney, and decided to see how far Lovable’s redesign skill could take the UI.
On the right: the original version I designed with Lovable earlier this year.
On the left: the redesigned version using Lovable’s redesign skill.
The difference is honestly huge.
Same product. Same core functionality. Completely different visual experience.
The redesign feels cleaner, more intentional, more modern, and significantly more polished.
0
17
What if the biggest risk in a visa application isn't a missing document but a contradiction between documents that nobody noticed?
That was the problem I needed to solve for VisaGuide, a platform working with a visa agency based in Hungary.
The business wanted applicants to upload their visa documentation, identify potential inconsistencies, understand what needed attention, and receive an Embassy Readiness Report before submission.
Rather than expecting one AI model to handle everything, I broke the problem down and assigned each tool a specific responsibility.
Here was my approach 👇
1. Azure Document Intelligence —> The Extractor 📄
First, I needed to turn uploaded documents into structured data.
The OCR and document extraction layer processes the documents and extracts relevant fields that can be compared across different sources.
2. ElevenLabs —> The Interview Simulator 🎙️
Documents alone don't always provide the full picture.
I included ElevenLabs for a virtual interview simulation, creating another way to collect information from applicants and complement the data extracted from their documents with option to switch to a manual progressive form.
3. Gemini —> The Auditor 🧠
This is where the different pieces come together.
Gemini receives the extracted document data alongside the information collected through manual forms or the interview workflow. The goal is to analyze the combined information, flag potential discrepancies, and produce actionable recommendations.
The output is an Embassy Readiness Report containing:
A readiness score.
Potential inconsistencies and issues requiring review.
Recommendations on what needs to be corrected, clarified, or aligned.
The architecture
User-uploaded documents → Azure Document Intelligence → Structured document data
Applicant information → Manual forms / ElevenLabs interview → Collected data
Structured document data + collected data → Gemini → Readiness score + issues + recommendations
What interests me most about this solution isn't simply the use of AI. It's the orchestration: combining document intelligence, conversational data collection, and AI-powered analysis into one business workflow.
Because building useful AI products isn't just about choosing the most powerful model.
It's about knowing which problem each tool should solve, what data should flow between them, and how to turn the output into something people can act on.
The objective is to help applicants and visa professionals catch avoidable documentation inconsistencies earlier not to guarantee visa approval or replace professional judgment.
I'm curious: if you were architecting this system, what would you add to make the analysis more reliable rule-based validation, confidence scoring, human review, or all three?
#BackendEngineering #AIEngineering #SystemDesign #DocumentIntelligence #SaaS
0
27
Project Overview
VisaGuide is a web platform designed to simplify visa application preparation through guided workflows, document organization, and intelligent readiness checks.
The platform helps applicants navigate the preparation process step by step, identify missing or inconsistent information, and prepare supporting documents before submitting their applications.
The Challenge
Visa applicants often struggle with complex requirements, scattered documentation, lengthy application forms, and inconsistencies between their answers and supporting evidence.
The goal was to deliver a more structured digital experience that guides users through the preparation process and makes outstanding requirements easier to identify.
Key Product Capabilities
Guided application workflows: Structured, adaptive questions based on the applicant's visa journey and previous answers.
Document management: Upload and organize supporting evidence for an application.
Readiness checks: Identify missing information and potential inconsistencies between responses and uploaded documents.
Document drafting: Generate supporting-document drafts from applicant-provided information for review and editing.
Application progress tracking: Help users understand their progress and outstanding requirements.
Destination-specific workflows: Organize visa preparation requirements around the selected destination and visa category.
Engineering Focus
The project demonstrates the engineering considerations involved in building a workflow-driven web application, including structured application data, conditional flows, document-related processes, and the coordination of multiple stages in a user journey.
Outcome
A live visa preparation platform that brings guided interviews, supporting-document preparation, and application-readiness checks into one user experience.
Live website: https://www.myvisaguide.app/
VisaGuide provides application preparation guidance, not legal advice or guaranteed visa outcomes.
1
65
Chamber by Bilma — Turning Legal Enquiries Into a Structured Client Journey
I approached this challenge by asking a slightly different question:
What would happen if a legal practitioner's entire first client interaction was designed as a system, rather than a collection of forms, messages, and calendar events?
That became the foundation for Chamber by Bilma.
🔗 Explore the product:
chambers.bilma.me (http://chambers.bilma.me)
The problem I focused on
For many legal practitioners, the problem isn't simply getting enquiries.
It's what happens after someone says, "I need a lawyer."
A typical journey can involve:
Enquiry → WhatsApp/email → asking questions → collecting information → checking conflicts → discussing availability → scheduling → reminders → consultation → follow-up.
Every step creates opportunities for things to get lost, delayed, or duplicated.
So rather than building another simple appointment-booking interface, I designed Chamber around the idea of a digital front door for legal practitioners.
My core product idea
I wanted three things to work together:
1. Discovery
Clients should be able to find a legal practitioner based on their actual legal need.
2. Structured intake
Once they find the right practitioner, Chamber should collect the information needed to understand the enquiry before the consultation.
3. Operational automation
Once a consultation is booked, the system should handle availability, calendar synchronization, reminders, and virtual meeting creation instead of making the practitioner manually coordinate everything.
That led to this journey:
Discover → Trust → Select a service → Intake → Book → Consult → Review
I designed Chamber around the practitioner, not the booking
One of my biggest architectural decisions was treating each legal practitioner as an independent tenant.
A practitioner can configure:
Professional profile
Practice areas
Services
Pricing
Consultation duration
Virtual/physical availability
Google Calendar
Professional links
Case studies
Reviews
Their public profile becomes their professional entry point:
chambers.bilma.me/esq/@username
This means the client isn't really "booking Chamber."
They're booking a specific legal professional and a specific service.
That distinction influenced a lot of the UX.
A global client identity
Another problem I wanted to solve was identity.
A client shouldn't need a different account every time they work with a different lawyer.
So Chamber uses a global customer identity with independent practitioner relationships.
For example:
Obi → Practitioner A
Family Law
Obi → Practitioner B
Corporate Law
Obi → Practitioner C
Property Law
The customer's identity remains the same, while each practitioner's private workspace remains isolated.
This became an important architectural principle:
One Chamber identity. Many professional relationships. Completely isolated legal workspaces.
Smart Intake
I deliberately avoided making the intake experience feel like a traditional long legal form.
The idea is progressive disclosure:
One useful question at a time.
The questions adapt based on the selected legal service and the client's answers.
For example, a family-law enquiry may require very different information from a startup legal consultation.
The system can collect things such as:
What type of legal help is needed?
Who needs legal help?
Relevant parties
Description of the matter
Urgency/deadlines
Contact information
The goal is to collect enough information to make the consultation productive without overwhelming the client.
Calendar automation
I also wanted the practitioner's calendar to become part of the workflow rather than another disconnected tool.
Practitioners can connect their Google Calendar.
Chamber can then use calendar availability to help prevent double-booking and create consultation events.
For virtual consultations, the booking can also create the appropriate Google meeting experience.
So the workflow becomes:
Client selects service → selects available time → booking confirmed → calendar event created → virtual meeting attached → reminders sent.
The practitioner doesn't have to manually recreate the appointment in another system.
Discovery became a product layer
During the process, I realized that Chamber shouldn't only solve the problem of managing existing enquiries.
It could also become a discovery platform for legal practitioners.
That's why I introduced:
Find a Lawyer
Clients can discover practitioners based on things such as:
Practice area
Legal service
Location
Consultation format
Pricing
Experience
Availability
Each practitioner has a richer professional profile containing their services, experience, case studies, and client reviews.
I intentionally avoided a simplistic "Best Lawyers" leaderboard.
Instead, reputation is represented through factual signals such as:
Verified professional information
Years of practice
Completed consultations
Verified reviews
Published case studies
Profile completeness
The objective is to help clients make an informed choice rather than pretending that one opaque score can determine who is the "best" lawyer.
Case studies and reviews
I also wanted practitioners to be able to demonstrate experience without exposing private client information.
So private matters and public case studies are deliberately separated.
The intended workflow is:
Matter → Create case study → Sanitize → Practitioner review → Publish
A case study should never automatically become public simply because a matter exists.
Likewise, reviews are tied to qualifying completed consultations rather than allowing arbitrary public testimonials.
This creates a more trustworthy reputation layer while respecting the sensitivity of legal work.
Privacy was part of the architecture
Because Chamber deals with potentially sensitive legal information, privacy couldn't simply be a page in the footer.
It had to influence the architecture.
Private practitioner data is tenant-scoped.
A practitioner should never be able to access another practitioner's:
clients
matters
notes
conflict information
appointments
internal analytics
Likewise, clients only see information they're authorized to see.
The platform uses Supabase authentication and row-level security to enforce these boundaries at the data layer rather than relying solely on frontend restrictions.
The client experience
I also redesigned the client side around a simple question:
"What does this client need to know right now?"
Instead of an empty dashboard, the client gets a home base for:
Upcoming consultations
Pending requests
Recent consultations
Their lawyers
Notifications
Profile completion
Finding another lawyer
The experience intentionally remains much simpler than the practitioner dashboard.
A client isn't managing a legal practice.
They're managing their relationship with legal professionals.
What I wanted Chamber to feel like
The visual direction was deliberately restrained.
I didn't want the typical:
⚖️ scales
🔨 gavels
✨ gold gradients
📸 generic law-firm stock photography
Instead, I went for a modern legal-tech aesthetic:
Deep blue + sky blue + warm neutrals + clean typography + generous whitespace.
The goal was to make Chamber feel like professional infrastructure, rather than a traditional law-firm website.
What I learned from building it
The biggest lesson for me was that the interesting part of this problem isn't the calendar.
It's the system surrounding the calendar.
A booking is only useful when the right person is booking the right service, the practitioner has enough context, conflicts can be reviewed, availability is accurate, the appointment is properly created, and both sides know what happens next.
That shifted my thinking from:
"Build a booking platform."
to:
"Design the infrastructure that turns a legal enquiry into a structured professional engagement."
That's what Chamber by Bilma is trying to become.
Explore the build
🔗 chambers.bilma.me (http://chambers.bilma.me)
Built with Lovable + Supabase, with Google Calendar integration and a multi-tenant architecture designed around legal practitioners and their clients.
No video submission — I wanted the product and the thinking behind the product to speak for themselves.
0
85