Build a Free CRM with Base44: Prompt, Results and Limits

This was a fictional handyman business, not a customer-ready service. The app stayed in preview. The test was recorded on October 30, 2026.

Cedar Lane Handyman needed a way to track quote requests through New, Quoted, Booked and Completed. Each inquiry had a customer name, job summary, USD estimate, next follow-up and notes.

The app opened with three fictional inquiries. Alex was overdue, Jordan was due that day, and Casey was upcoming. Those labels used a fixed scenario date of October 30, 2026, shown in the app header. They were not calculated from the date a viewer watches the video.

The amounts were quote estimates, not revenue or payments. There were no real customer details, invoices, email campaigns or calendar connections.

The original brief supplied this core prompt and the three starting records below. The filmed build used the brief and seed records. Keep the fixed scenario date when reproducing this demonstration; replace it deliberately if building a different app.

Build an internal web CRM for Cedar Lane Handyman, a fictional solo handyman business. Track inquiries through New, Quoted, Booked and Completed. Each record has a unique reference, customer name, job summary, USD quote estimate, status, date-only next follow-up and plain-text notes. Let the owner create a record, open and edit it, search by customer, and filter by status. Save records persistently using the platform's native included backend and authentication, once any required setup is approved. Reject a blank or whitespace-only customer name or job summary, a negative USD estimate, and an invalid date. Show a useful message and do not save invalid input. Show a simple open-jobs list and a follow-up list. Open means New, Quoted or Booked. Completed jobs remain in history but disappear from open jobs and follow-ups. For this demonstration, use October 30, 2026 as the fixed scenario date and display "Scenario date: Oct 30, 2026" in the header. Calculate follow-up groups from that scenario date, not the current clock. Mark an open record overdue only when its follow-up is before that date. Show due-today separately. Use the three starting records in section 1 exactly. Provide a clear empty state. Require an owner login for business records; do not use a visible role-switch button as proof of access control. Make the layout usable at a 390px phone width. No payments, invoices, email, SMS, calendar sync, AI assistant, scraping or external integrations beyond the approved native backend/auth needed for these requirements. Do not add extra features.

CL-101 | Alex Reed | Repair a sticking door | New | $120 | Next follow-up October 29, 2026 | Note: Asked for a quote. No reply recorded. CL-102 | Jordan Lane | Fit two shelves | Quoted | $240 | Next follow-up October 30, 2026 | Note: Quote sent. Waiting for a decision. CL-103 | Casey Park | Patch a wall | New | $180 | Next follow-up November 2, 2026 | Note: Asked for a quote. Send after photo review. ```

A new job stayed after a reload

We added Morgan Dale's cabinet-handle job with a $75 estimate and a November 3 follow-up. The open count rose from three to four. Searching for Morgan found the record. After a reload and reopen, the saved details were still there.

Four edits stayed together

On Alex's record, we changed the status to Quoted, estimate to $135, note to "Called back. Quote sent. Awaiting approval.", and follow-up to November 2. All four changes remained after saving, reloading and reopening. Alex left the overdue list, while the open count stayed at four.

Completed work stayed in history

Jordan moved from Quoted to Booked, then Completed. The open count fell from four to three. Jordan disappeared from open follow-ups but remained searchable in completed history after another reload.

Search, filters and input checks worked on the tested paths

The status filters matched the saved records. Searching for Alex returned Alex, while a name that did not exist produced an empty state.

Blank and whitespace-only customer names and job summaries were rejected, as was a negative estimate. The impossible-date attempt did not save a record. Chrome's date control contributed to that result: the app showed its missing-date message rather than proving a separate impossible-date check of its own.

The phone-width edit persisted

At an emulated width of 390 pixels, we edited Casey's note, saved, reloaded, searched and reopened it. The added note stayed. This was Chrome device emulation, not a physical-phone test. The status chips scrolled within their row.

Signing out showed a login screen. But a fresh signed-out session could still retrieve all four fictional customer records from the app's records address. A newly registered test user could also see the owner's workspace.

That matters more than whether the dashboard looks finished. Hiding a page behind a login screen does not, by itself, prove that the stored records are private.

We asked Base44 to restrict record access to the owner. After the repair, the fresh signed-out records request returned an empty list, and the second user saw zero records. The owner still had three open jobs and one completed job.

That is an improvement on the read paths we checked. It is not a security audit. We did not test the second user's create, edit or delete permissions after the repair. We also did not test a published deployment. A visitor could still sign up and reach an empty workspace.

Before putting real customer data into an app like this, check the actual read and write rules for signed-out visitors, ordinary users and the owner. Do not infer them from a login screen or the builder's completion message.

The recorded allowance increased by 1.00 message credit for the build and 1.37 for the repair: 2.37 message credits in total. Integration usage did not change. These are this run's measured figures, not a guaranteed cost to reproduce the app or a promise about today's plan allowances.

For broader background on Base44, read our Base44 review. This build guide covers a different use case.