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

From foster to forever home

Who does what in the team, the app at every step of an animal's life, and what comes next. This page goes with the Bicho Feliz NGO case.

    The team

    Many small jobs, done by different people

    Many people help an animal find its family. Each role sees its own part of the work, and nobody needs all of it.

    Around them, finance, and admin, who can see and do everything in the app.

    The app

    Seven moments in the life of one animal

    For each one: how it was, how it is now, and the decision behind it.

    Only the basics, and the record is there.

    1 · Intake

    In the app the moment it arrives, the rest later

    Before
    1. Fill in a row in the spreadsheet
    2. Open Drive
    3. Create the animal's folder by hand
    4. With luck, upload some photos
    Now
    1. A name, cat or dog, and the type of foster
    2. The folder creates itself

    The record starts on a phone, usually with an animal in one hand. Only the basics are required: a name, cat or dog, and the type of foster. The photo is optional, but it sits near the top on purpose, and three of the first four animals the team added came in with one. Everything else can wait, and the app keeps count of what is still missing.

    One manual task less

    The folder is created on the spot, always one tap away in the app, and named the same way for every animal: its name and the foster carer's nickname.

    A face for every animal

    If there is a photo, it goes into the folder too. The spreadsheet often had no way to put a face to an animal, and in the follow-ups it is how I know which one is Pepito.

    Go deeper: what I considered
    Trade-offI ruled out a longer first screen. What we needed was the basics, fast: which volunteer has which animal, and how many there are. The rest can always be filled in later.
    From a to-do to the record, then filling in what is known.
    Yes or No, nothing selected at the start.

    2 · Getting to know it

    The record fills in as the animal is known

    Before
    1. 32 columns, for whoever is holding the animal
    2. A blank cell: no, or nobody answered?
    Now
    1. Easy to see what is still missing
    2. An unanswered question counts as missing

    Some things nobody knows on day one: whether it gets on with other cats, whether it likes a cuddle. The record fills in as the animal is known.

    Each record is split in sections that open and close, and every section counts what is still missing.

    The decision I would defend: yes, no, or not answered yet

    In the spreadsheet a blank cell meant no, or that nobody had looked. Now every question has two boxes, Yes and No, and neither is selected at the start. Behind them it is still a yes or no, but it starts empty, and empty counts as missing. Not answered yet is information too.

    Every animal is one of a kind

    The temperament column was lovely to read and impossible to filter. So the form keeps chips for the clear cases, and free text for everything that makes each animal who it is, like "gets on with dogs, though she is frightened of them for the first week".

    Dated, signed, newest first.
    The same history, in the spreadsheet: one cell.

    3 · The health recordStar feature

    The feature we did not know we needed

    Before
    1. One cell for the whole treatment
    2. Anyone can add to it, at any time
    3. Nobody knows which line is the latest
    Now
    1. One entry per event, dated and signed: a vet visit, a new pill
    2. Marking neutered or vaccinated adds its own entry, on that date
    3. Newest first, the whole history one tap away

    In the spreadsheet a whole treatment lived in one cell. Everybody appended to it, it grew until it took a third of the screen, and the latest news ended up buried in the middle. It was one of the biggest problems we had.

    The feedback on the first version was that they only needed the latest visit to the vet. Entries were my answer, and they got the biggest reaction of anything I built.

    Go deeper: what I considered
    TriedOne text field for treatment, the same as the cell everybody appended to.
    Turning pointThis feature is one of the reasons I moved the app to code. In FlutterFlow, building it by hand was getting hard, without really understanding how the data was shaped or how it travelled.
    On a phone: the counters are the filters.
    On a desktop: the same screen, rearranged to use the space.

    4 · Kept up to date

    An animal can only be offered when its record is complete

    To be offered, an animal's information has to be there, and current. One still in treatment, for example, cannot be offered yet. So one volunteer's work is to make sure everybody else's records are up to date.

    Before
    1. Open the spreadsheet
    2. Check every column of every animal
    3. Work out who is missing what
    4. Write to each foster carer
    Now
    1. Each card names what is missing
    2. The counters are the filters
    3. The message is already written

    My plan was to message foster carers one to one from there. The volunteer who does this preferred to paste it into the group, where the rest of the conversation already lives, so the app writes the message and she pastes it.

    One decision against my own rule

    I had built buttons that only appear when their conditions are met. She preferred to mark things as reviewed even when they were not, and since she is the only person who uses this section, I fitted her work instead of generalising mine.

    Phone first, then desktop

    The desktop version started as the phone, stretched. Once everything was in place I went back and rearranged it to use the space.

    Go deeper: what I considered
    Ruled outDragging cards to the top, as in the sheet, so the rest of the team can see which are ready. The follow-up coordinator asked for it. I told her it was not needed: once she marks the photo as ok, the animal moves on its own to the other area's pending list, even if other things are missing.
    The app says who they are before anyone offers them an animal.
    Address checked, family confirmed, new name, and a family found.

    5 · Adopted

    A person, not an email

    Before
    1. Contacts as emails hanging off each animal
    2. A photo of an ID in the animal's folder
    3. No way to know they had adopted before
    Now
    1. One person, one record
    2. The app says if they adopted, volunteer or are flagged
    3. "Address checked", by whom and when

    Contacts lived as emails on each animal, so the same person could appear many times. Now each person is one record, matched by their email, and what we know about them shows up the moment they are moved to "in contact".

    An animal cannot be marked as adopted without the adopter's details. The adoption also asks for the new name the family chose, and the email uses it, because that is who they live with.

    The proof of the proof

    We used to keep a copy of the adopter's ID and a bill in their name, only to show that the volunteer had asked for them. Neither told us anything. What we needed to know was that the address had been checked, so that is what the app records.

    Another task off someone's plate

    When an animal was adopted, its Drive folder had to be moved by hand, and a volunteer checked that it had been. Now the app moves it.

    Go deeper: what I considered
    ChoseEditing is open, changing the state is not. Anyone who learns something true about an animal can edit it. Marking it as adopted is a decision: it opens an adoption and, a hundred days later, sends an email.
    FixedThe adoption form asked "Did you change its name?" above a free text field. Several people answered "Si", and "Si" was saved as the animal's name, the one the follow-up email would greet the family with. The label now says "New name", and the field refuses "si" and "no".
    Every adoption, with the days since the email and what is still pending.
    The first email, 100 days after the adoption.

    6 · A hundred days later

    Every Thursday the emails go out, and I answer the replies

    Before
    1. Once a month, sit down with a Gmail template
    2. Match adopter, animal, sex and neutering by hand
    3. Write ten or more emails in one go
    Now
    1. Every Thursday the emails go out on their own
    2. I answer the replies, a few at a time

    What I wanted automated was the remembering, not the caring. Every Thursday the app writes to the families whose adoption turned 100 days, grouped by household and worded for each animal. I read every reply, and answering a few in spare minutes is much easier than one long evening of writing.

    It sends, I follow up

    The app sends the email. I check who replied and act on it, and it never writes twice on its own.

    The same email I used to write

    The automatic email is exactly the one I used to send, with each family's details already in place, without the time it took me to change them by hand.

    Go deeper: what I considered
    ChoseA weekly batch, not the exact day. Nobody gets an email at three in the morning on a Sunday, and it is how I already worked.
    From the record to the memorial, in a few taps.

    7 · The other ending

    It says thank you before it asks for anything

    Before
    1. No clear place for it
    2. Mixed in with the rest, or moved to another sheet where its history got lost
    Now
    1. A thank-you for looking after the animal
    2. A date, and two optional notes: one for the memorial, one for the record
    3. A place in the memorial

    Not every story ends in an adoption. When an animal died in foster, there was no clear place for it: it stayed mixed in with the others, or went to another sheet where everything anyone knew about it got lost.

    The record stays, in a memorial. The memorial is not a list: it has no search, no filters and no counter.

    Still iterating

    What I want to do and have not done yet

    The volunteers use it every day. And there are still plenty of tasks to automate and processes to improve.

    In progress 3

    The contract
    The app can generate the contract and have it signed on a phone. It is in beta, and the next step is testing it with the team.

    Almost there

    Editing contacts
    Animals and team members can already be corrected in the app. The contacts of the people who adopt are next.

    Almost there

    Expenses and reimbursements
    The expenses tab is in the demo, being tested with the volunteer who handles the finances. Where I want to take it: invoices and expenses tied to each animal, in one place, so we can see where the money goes and how it splits between providers and animals.

    Next 5

    The round of supplies
    Today it is an Excel sheet. I want to use what I learned about routes and deliveries at Mercado Libre to plan the rounds: which stops come first, and how to run them with less load on the volunteers.

    Animals in adoption, on the website
    Connect the database to the site, so the animals in adoption show up there with the information that matters, and not only on Instagram.

    More interactive notifications
    Messages that let people act on them, not only read them.

    Reports
    Reports the administrators can download whenever they need them.

    A safe copy, and backups
    Automatic backups and a copy of the database to test on, so the NGO does not depend on the app alone.

    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 →

    Bicho Feliz NGO · In detail Building it with AI From FlutterFlow to Claude Code on the same database, and the data model underneath.
    The database schema of the app
    Try it yourself