← Bicho Feliz NGO, the case
Bicho Feliz NGO · In detail

Building it with AI

How I built the app the volunteers use, with FlutterFlow first and Claude Code after, on the same database. This page goes with the Bicho Feliz NGO case.

    How I worked

    Beyond pixels and screens

    I had seen this problem for years. When I wanted a project to build with AI, it was the first thing that came to mind.

    So I wore every hat it needed.

    Research

    One chat with the area coordinators when everyone needed to weigh in, one to one for the specifics: what to prioritise, what to cut, what a column was really for.

    Product manager

    Deciding what to build and what to leave out, with the coordinators of each area.

    Designer

    Every screen, phone first, then rearranged for the desktop.

    Data modelling

    The tables underneath: what an animal is, what a person is, and who can change what.

    Builder

    Guiding Claude Code, testing what it built and versioning it in Git.

    QA

    Using it next to the spreadsheet, and watching the coordinators use it.

    Working with AI

    I worked out what to build, so Claude could write the code

    I have always liked code, and being close to it. But learning to build an app from scratch was not going to be quick. So I built the first version by hand, in FlutterFlow, and then guided Claude Code to rebuild it, on the same database.

    What I brought

    The data structure, already built and working: the tables, the relations and the logic. The product decisions, made with the coordinators. And the checking: using it, and watching the coordinators use it.

    What Claude wrote

    The React code, from my structure and my decisions. I follow what it does and ask for the changes.

    Built with FlutterFlow (first version) · Supabase (database) · Next.js on Vercel · Claude Code · Git and GitHub · Google Drive (folders and photos) · Resend (every email the app sends)

    Go deeper: why these tools
    Ruled outLovable and Glide. Both meter usage, and an NGO cannot have its records go read-only when a credit runs out.
    ChoseThe database stays the same. The interface moved from FlutterFlow to code without moving a single record.
    How it got here

    The first version looked like a first version

    I started in FlutterFlow, and it showed. One screen, then and now, and what I learned underneath it.

    The first version, in FlutterFlow: an animal record with ticks and crosses, everything open at once The record today: sections that open and close, each counting what is still missing

    The same record, a few months apart

    • Ticks and crosses became sections that count what is still missing.
    • Everything open at once became sections that open and close.
    • An empty field now says so: "missing, add it".
    The Supabase schema: related tables for animals, their health, foster placements, volunteers, contacts, neighbourhoods, adoption enquiries and adoptions
    The tables, and how they hold on to each other.

    What I learned

    Modelling data was the new part

    What an animal is, what a stay in a foster home is, what a person is, and how they connect. If the tool changes, this stays.

    An animal is not a placement

    The animal is one record and each stay in a foster home is another, so a history does not get overwritten every time it moves.

    A person is one row

    Whether someone volunteers, has adopted or is flagged lives on that person, not on an email hanging off an animal.

    A copy of a fact drifts

    folder_ok copied something that lives in Drive, so it went: the app moves the folder now. doc_ok and family_photo stay, for the person who follows up on the adoption paperwork.

    Learnings

    What I would do again, and what I would not

    Build it by hand first
    Doing the tables and the logic myself in FlutterFlow is where I learned the most. I would start there again.
    Give the visual side time earlier
    A tool that first had to work came first, and that was the right order. Some things were harder to rethink visually later.
    Lucila Di Vanni Frick

    Hola, I'm Lu. Senior Product Designer, 6+ years across different industries. I start with the real problem, make complexity understandable, and stay close to the outcome. More about me →

    Try it yourself