GAARD Capital CRM
A working prototype of the CRM that replaces the outreach spreadsheets. One
file, no build step, no server. Open it and it runs.
Everything in it is fictional. Email addresses use the reserved .example
domain and phone numbers use the reserved 555-01xx range, so nothing in here
can reach a real person.
Run it
Open index.html in any browser. That is the whole install.
To work on it locally, serve the folder so browser storage behaves normally:
python3 -m http.server 8765
Then open http://localhost:8765/index.html
OR go open https://gaard-capital.github.io/gaard-crm/
Put it on the web
GitHub Pages serves this repository as it stands.
- Settings, then Pages.
- Source: Deploy from a branch.
- Branch:
main, folder: / (root). Save.
- Wait a minute, then open the URL Pages shows you.
index.html is at the root, so the site URL needs no path. The .nojekyll
file stops GitHub trying to process the folder as a Jekyll blog.
A public repository means the code is public. The data inside is invented, so
nothing confidential is published, but anyone can read it.
What it does
| Screen | What it is for |
|---|
| Dashboard | the work waiting on you, and whether the outreach is landing: the headline numbers, the funnel from emails sent to funded with the conversion between every stage, and today's email queue |
| KPIs | the same period cut further: eight cards, the charts, what happened lane by lane, warm against dormant, and the emails by state. Pipeline sits beside it as a tab |
| Follow-ups | the shared reminder list, one at a time or as a batch mail merge, with a tab for outreach that went nowhere |
| Contacts | the master list as a spreadsheet, with Organizations and Correspondence as tabs. Every cell edits in place |
| Newsletter | the subscribers, as the same sheet |
| Partners | benefit groups and referral partners, the firms to work with rather than sell to |
| Reviews | funded accounts and when each is next owed a performance report, on a quarterly, semi-annual or annual cadence |
| Events, RFPs | what each event cost and produced, measured against cold email, and the RFP tracker |
| Import | paste or upload a sheet, every row checked against the master list before anything is written |
| Workflow | how a name becomes a funded client, step by step |
| Settings | the configuration tables, the email templates, and what is not connected yet |
Nothing is typed in twice. Every figure is counted from the touchpoints,
opportunities and reminders, so there is no separate reporting tab to keep up
to date.
How it is built
index.html is one file of plain HTML, CSS and JavaScript. No framework, no
dependencies, no bundler. The only network request is a Google font.
It has eight labelled sections:
- Reference data. Categories, channels, outcomes and the rule each outcome
triggers. These are rows, not code, so the wording can change without a
developer.
- Embedded data. A snapshot of every table, stored column first to keep the
file small.
- Data access. A small layer whose method names match the SQL views the real
application will call. This is the seam.
- Metrics. Everything the dashboard shows.
- Intelligence. The import pipeline: column mapping, duplicate detection,
outcome wording, AUM classification.
- Rules. Follow-up scheduling and business day arithmetic.
- Views. The screens.
- Router and boot.
Edits are kept in the browser under one storage key, so a demo can be changed
freely and reset from Settings.
Connecting a real database
Everything database-side is under db/: the base schema (db/base/, or all of it in one file,
db/gaard_crm_install.sql), the numbered changes made since (db/001_... onward, run by hand in the
SQL Editor, in order), two self-rolling-back test files (db/tests/, 66 checks), the docs
(db/docs/: database write-up, workbook import playbook, dashboard connection guide) and mock data
only (db/mock/). db/README.md has the order of operations for a fresh project.
Never commit client data, uploaded CSVs, the secret key or the database password.
What is not connected yet
Written down in the application itself, under Settings.
- Sending email. The merge screen fills the letters and records that they
were sent. The sending happens in your own mailbox. To make the button
really send: a sending service or mailbox, a verified sending domain, and a
reply address that posts replies back in.
- Calendar invites. Nothing writes to a calendar, deliberately. When it is
built, the invite is drafted from the confirmed thread and shown for review,
and a person confirms the time, the attendees and the link before it is sent.
- The database. The prototype reads the embedded snapshot. Supabase is the
data layer.
Changing it
The whole application is one file, so a change is one edit and a refresh.
Search for the section banners to find your way around.
