Hello Sariyah.
You're going to build and run a real app.

Before you build anything, get your accounts working and spend an hour clicking around Lovable with something throwaway. Nothing you make today has to survive.

Where things live

Make a scratch project in Lovable first — anything, a page about your favourite food. Send it five messages. Watch what happens when you ask for two changes at once versus one. That hour will save you a week.

Checklist

• Log into Lovable and confirm you can see the SJ Finance workspace
• Make a throwaway scratch project and send it at least five messages
• Deliberately ask for three changes in one message — see how it goes
• Find the preview, the code view, and the publish button in Lovable
• Read the "How the app is put together" section further down this page

The foundation. A property is a house. A unit is a rentable space inside it. A whole-house rental is just a property with exactly one unit — that sounds fussy now, but it's what lets both Edraya houses work in the same app.

Three prompts, in order. Send one, check the preview, then send the next. Don't run ahead.

Build an internal admin web app called "Edraya Manager" for a small
property company. Only signed-in admins use it. There is no public
side and no tenant-facing side.

Build only this, nothing more:
- Email and password login using Supabase auth. No public sign-up —
  accounts are created by an admin.
- After login, a sidebar layout showing the app name "Edraya Manager"
  with one nav item: Properties.
- A Properties page listing properties in a table with columns:
  name, address, number of units. If there are none, the empty state
  says "No properties yet."
- An "Add property" button that opens a form with: name, street
  address, city, state, ZIP, notes.
- Store properties in Supabase.

Style: calm and clean, lots of white space, deep green and warm brass
accents, plain readable type.

Do not add any feature I have not asked for.

Now add units.

- A unit belongs to exactly one property. Fields: label (for example
  "Unit A" or "Whole house"), bedrooms, bathrooms, notes.
- Clicking a row on the Properties page opens a property detail page
  showing that property's information and a table of its units.
- Put an "Add unit" button on that detail page.
- The Properties list should show a live count of units per property.

Do not add tenants or leases yet.

Add editing and deleting for both properties and units.

- Edit opens the same form, pre-filled.
- Delete asks me to confirm first.
- Deleting a property that still has units should be refused, with a
  clear message explaining why.

Then add two example properties so I can see it working:
1. "Maple Street House" — one unit labelled "Whole house", 3 bed, 2 bath.
2. "Oak Avenue Duplex" — two units, "Unit A" (2 bed, 1 bath) and
   "Unit B" (2 bed, 1 bath).

Label these clearly as example data.

Checklist

• Send prompt 1 and log in successfully
• Send prompt 2 and open a property's detail page
• Send prompt 3 and confirm the two example houses appear
• Try to delete a property that has units — check it refuses
• Refresh the browser and confirm nothing was lost
• Tell Shahed it's working and show him the preview link

A tenant is a person. A lease is the agreement putting that person in a unit for a rent, between two dates. Keep them separate — the same person can have a new lease later, and you don't want to retype them.

Here's the start of the prompt. You write the rest. Before you send it, ask Claude: "what am I missing from this prompt?" — then decide for yourself whether it's right.

Add tenants and leases to Edraya Manager.

- A tenant has: full name, email, phone, notes.
- A lease connects ONE tenant to ONE unit, and has: monthly rent,
  start date, end date (may be blank for ongoing), and status
  (active or ended).
- A unit can only have one active lease at a time. If I try to add a
  second, refuse it and explain why.

[ Your turn. Add instructions for:
  - where tenants are listed and how I add one
  - what the property detail page shows now that units have tenants
  - what a unit with no tenant looks like
  - two example tenants on the example properties ]

Checklist

• Write the rest of the prompt yourself, before asking Claude
• Ask Claude what's missing, and decide which suggestions to take
• Build it and add two example tenants
• Test the double-lease rule — confirm it refuses
• End a lease and confirm the history is still there

No prompts from here on. You get requirements and a definition of done. Writing the prompt is now your job — that's the skill this whole month is really teaching.

An invoice is a bill for one lease for one month. It is not a single rent number: it's a list of lines that add up.

Requirements

• One invoice belongs to one lease and covers one month.
• An invoice is made of line items. Each line has a kind, a description and an amount. The five kinds are: rent, utility, late_fee, charge, credit.
• A credit is negative — it reduces the total.
• Generating a month's invoice for a lease should pre-fill the rent line automatically from the lease. Everything else is added by hand.
• An invoice has a status: draft, sent, paid, overdue.
• There must be a clean printable view of a single invoice — something you could save as a PDF and email.
• Money is stored in whole cents, never as a decimal. Ask Claude why if that's new to you. It matters.

Checklist

• Write your own prompt from these requirements
• Build invoices with all five line kinds
• Check the maths by hand on one invoice with a credit
• Print one invoice to PDF and look at it properly
• Show Shahed the printed invoice before moving on

Money in, money out. This is the phase that makes the app worth using instead of a spreadsheet.

Requirements — payments

• A payment is recorded against an invoice: date paid, amount, method (cash, cheque, transfer, other), note.
• An invoice can have several payments — people pay in parts.
• Every invoice shows amount due, amount paid and balance.
• An invoice flips to paid on its own when the balance reaches zero.
• An unpaid invoice past its due date shows as overdue without anyone clicking anything.

Requirements — expenses

• An expense belongs to a property: date, category, amount, vendor, note.
• Categories at minimum: repairs, maintenance, utilities, insurance, tax, other.
• A property's detail page shows its total expenses for a chosen month.

Requirements — the dashboard

• A home screen showing, for the current month: total invoiced, total collected, total outstanding, total expenses.
• A list of overdue invoices, worst first.
• A list of vacant units.

Checklist

• Build payments and test a part payment
• Build expenses with all six categories
• Build the dashboard
• Check every dashboard number by hand on paper
• Walk Shahed and Shahera through the whole app

Building it is half the job. Putting it somewhere real, on a proper address, with real accounts — that's the other half, and most people never learn it.

What happens

1. Publish the project in Lovable. You get a .lovable.app address straight away.
2. In Lovable's settings, add the custom domain edraya.sjinnovation.us.
3. Lovable gives you a DNS record. Shahed adds it — the domain isn't yours to change.
4. Wait. DNS is slow; a few minutes to an hour is normal. Don't panic and change things.
5. Create the three real admin accounts: Shahed, Shahera, you. Delete any test accounts.
6. Check on a phone. Not just your laptop.

Before Shahed puts real tenant data in, go through the app and delete every example property, tenant, lease and invoice. Real and fake data must never sit side by side — that's how a made-up rent ends up on a real invoice.

Checklist

• Publish in Lovable and open the default address
• Add the custom domain and send Shahed the DNS record
• Confirm https works on the real address
• Create the three admin accounts, remove test ones
• Delete all example data
• Open it on your phone and use it for five minutes

An app nobody maintains rots. This phase is how you own it properly.

Your monthly rhythm

• Generate the month's invoices and check each one before it goes out.
• Record payments as they arrive, not in a batch at month end.
• Enter expenses with receipts to hand.
• Export a backup of the data and keep it somewhere outside Lovable.
• Send Shahed a short note: what happened, what's outstanding, anything odd.

When something breaks

1. Write down exactly what you did and exactly what happened. "It's broken" isn't a bug report — not even to yourself.
2. Copy the error message. All of it.
3. Ask Claude to explain the error in plain language before you try to fix it.
4. Fix one thing. Check. Then fix the next.
5. If two attempts don't fix it, stop and ask Shahed. Don't spend the afternoon.

Changing a live app

Once real data is in there, you can't experiment freely any more. Small changes to how something looks are fine. Anything that touches the data — new fields, changed rules, renamed things — gets discussed with Shahed first, and a backup taken before you start.

Your code lives in the shahedsj/edraya repository on GitHub. Lovable saves there automatically. You don't need to run any commands, but it's worth opening once a month to see the history of what you changed.

Checklist

• Run one full month cycle: invoice, collect, record, report
• Take your first data backup and confirm you could restore it
• Write and send your first monthly note to Shahed
• Find the repo on GitHub and read a month of commits
• Make one small improvement you thought of yourself