Boardly
Boardly is a free, multi-landlord SaaS that replaces a boarding house's paper rent ledger with one system of record. Landlords manage rooms and boarders; the app bills each boarder on their own due date; boarders upload proof of payment by GCash or bank transfer; and the landlord confirms it to issue a sequential, tamper-proof receipt - with automatic email and in-app reminders for what's due. Boarders get their own invite-only portal to see their bill, pay, and keep their receipts. A full-stack product built to put a real boarding house's accounting on rails, live in production.
The problem
A boarding house runs on a paper ledger and a stack of carbon receipt booklets. The landlord tracks who's in which room, who has paid, who's late, and how much electricity each boarder owes this month - by hand, in a notebook, and over text messages. The real state of any month is whatever can be reconstructed from that notebook.
It works until it doesn't. A handwritten receipt gets lost or disputed, a boarder's due date drifts, the electricity split is redone from scratch every month, and chasing late rent is a personal phone call nobody enjoys making. None of it is hard; all of it is tedious, error-prone, and impossible to audit later.
Boardly exists to put that on rails: one system of record where rooms, boarders, bills, payments, and receipts live together, so the month's truth is in the app instead of someone's memory. The product's job is to make the careful way also the easy way.
Paper ledger to one system
Boardly is one product with two audiences. A landlord signs up, adds their property and rooms, and puts each boarder in a room with their rent, deposit, and the day of the month rent is due. From the dashboard they see the month at a glance: what's collected, what's pending, what's overdue, and what's coming due next.
Boarders never sign themselves up. The landlord invites them, and an invite link opens an account already linked to their room - so the boarder lands straight in their own portal, sees their current bill, and can pay without any setup. One codebase serves both sides, and each sees only what its role is allowed to.
It's a free, multi-landlord SaaS: more than one landlord can run their whole house on the same deployment, fully walled off from each other. The point is a single source of truth for a boarding house - replacing the notebook with something everyone in the building can trust.

Bills that build themselves
Rent isn't due on the first for everyone. Each boarder has their own due day, usually tied to when they moved in, so Boardly bills each one on their own cycle. A few days before a boarder's due date the app generates that month's bill and drops in the rent line automatically - the landlord never starts from a blank page.
Then there are the variable charges. Electricity is the usual one: the landlord enters a per-boarder amount, or a building total that Boardly splits evenly across boarders with a preview before it's saved. Water, wifi, or a one-off charge work the same way. A bill is just typed line items, so a new kind of charge needs no special handling.
The whole thing is driven by a single daily job that's safe to run over and over - a bill for a given boarder and month is only ever created once, no matter how many times the job runs or restarts. The landlord wakes up to this month's bills already drafted, not a chore waiting.

Proof in, receipt out
Most boarders pay by GCash or bank transfer, so payment in Boardly starts with proof. A boarder uploads a screenshot of the transfer against their bill, and it lands in the landlord's review queue as pending - never auto-confirmed. The landlord opens the proof, checks it, and either confirms or rejects it with a reason, and the boarder is told either way.
A confirmed payment issues a receipt, and the receipt is the part that has to be trustworthy. Receipts are numbered in a strict per-property sequence - RCPT-2026-0001, 0002, and so on - with no gaps and no races, even if two payments are confirmed at the same moment. Each receipt is a frozen snapshot of the bill at that instant: the boarder, the period, the line items, the amount. Edit the bill later and the receipt never changes, because a receipt you can rewrite isn't a receipt.
For cash, the landlord records the payment directly and the same sealed receipt is issued. Either way, every confirmed payment leaves a permanent, numbered record - the digital version of the carbon booklet, minus the lost copies.

Two portals, one codebase
Boardly is really two experiences over the same data. The landlord side is a workspace for running the house - rooms, boarders, billing, the payment-review queue, and settings. The boarder side is a small, focused portal: this month's bill, a way to pay, and a history of past bills and receipts. Each gets an interface shaped to its job, not one dashboard with half the buttons greyed out.
Crucially, nobody picks a role. There's no 'are you a landlord or a boarder?' switch and no role flag to get wrong. Your role is simply what you own - you're a landlord because you have a property, a boarder because you hold an active room. That keeps the two sides cleanly separate without a brittle settings field deciding who sees what.
The two portals come from one codebase and one schema, which is what keeps them from drifting apart as the product grows. A change to how a bill works changes it for both sides at once - the landlord who issues it and the boarder who pays it are always looking at the same thing.

Isolated at the database
With multiple landlords and their boarders on one deployment, the thing that absolutely cannot fail is keeping accounts apart. Boardly enforces that at the database, not just in the app: every table is governed by Postgres Row-Level Security, so a query only ever returns rows the signed-in user is allowed to see. If app code ever asks for the wrong data, the database returns nothing - the isolation is the floor beneath every feature, not a check that can be forgotten.
Roles are derived the same way, in the database. A small set of security functions answer questions like 'is this user the landlord of this property?' or 'is this the boarder on this tenancy?', and every access rule is built from them - there's no role column to escalate. Uploaded payment proofs live in a private bucket keyed by boarder, so a boarder can only reach their own files and a landlord only their own house's. A dedicated isolation test suite logs in as rival landlords and boarders and asserts that every cross-account read and write fails.
The rest of the stack is deliberately boring and cheap to run: Next.js with server components and server actions, Supabase for Postgres, auth, and storage, Zod validating every action's input, email that degrades gracefully when it isn't configured, and a single daily cron for billing and reminders. It runs on free tiers, which is the point - a tool for small landlords shouldn't cost money to keep alive.

Key decisions
A few constraints shaped the whole system and keep it trustworthy.
Isolation lives in the database
Every table runs Postgres Row-Level Security and roles are derived from ownership, never stored in a column. A bug in app code can't leak another landlord's house - the database returns nothing instead of someone else's data.
Receipts are sealed, never edited
A confirmed payment snapshots the bill into a numbered, per-property receipt that never changes. Editing the bill afterward can't rewrite history, the same way a paper carbon copy can't be un-signed.
The billing job is safe to repeat
Bill generation and reminders run from one daily cron built to be idempotent - a bill for a boarder and month exists once, and a reminder sends once, no matter how often the job runs or restarts after a failure.
Proof before receipt, always
Boarder payments land as pending proof for the landlord to confirm or reject; only a confirmed payment issues a receipt. The landlord is the quality gate, so the record is something both sides can trust.
Status and what's next
Boardly is live in production at boardly.cjjutba.com, with the source on GitHub. The full loop works today: a landlord sets up rooms and boarders, bills generate on each boarder's due date, boarders upload proof and pay, the landlord confirms and a sealed receipt is issued, and reminders go out for what's due - all of it isolated per account at the database.
It's free by design and built for a real boarding house. The honest next step is putting it in an actual landlord's hands and letting real use shape it, rather than dressing a fresh deployment up as traction it hasn't earned yet.
On the roadmap: an online payment hand-off so boarders can pay inside the app, sub-metered electricity by reading rather than a flat split, SMS reminders alongside email, and move-out settlement with deposits. As real landlords use it, this is where concrete, non-sensitive outcomes will go.
Coasta
One number tells you you're covered - native iOS cash-flow for freelancers with lumpy, late income.
Native iOS AppHave a project in mind? Let's build it.
I'm available for freelance projects, and open to the right full-time role.
I build web apps, SaaS, and MVPs for founders and startups. Tell me what you're working on.