How to build a lightweight CRM

What matters here

• A lightweight CRM is four parts: organisations, contacts, an interaction log, and a small pipeline with this team's stages.
• Decide the boundary with the company CRM first. Two systems tracking the same relationship with no rule about which wins is worse than either alone.
• Keep contacts separate from organisations. People move, and losing the history when they do is the most common design mistake.
• The interaction log is the value. A CRM without one is an address book with extra fields.
• Stages must mean something to this team. Copying the sales pipeline into a partnerships tool produces a pipeline nobody updates.
• Contact records are personal data with obligations attached, so scoped access and retention belong in the build.

Who this is for

You run partnerships, recruiting, investor relations, community or supplier management. You track relationships, and putting them in the sales CRM would be wrong for both of you. What you want is something small that does not pretend to be Salesforce.

How it works in practice

What a partnerships or recruiting team actually does with it, week to week.

1. 1

   Organisations and contacts are separate records

   Linked by a dated relationship, so when somebody changes company the history follows the person rather than vanishing.

2. 2

   Logging an interaction takes under thirty seconds

   Paste an email or notes and let the assistant draft the fields. Interaction logs stay empty when filling them in is tedious.

3. 3

   The pipeline uses this team's stages

   Introduced, exploring, agreed in principle, contracted, live. Copying the sales stages produces a pipeline nobody updates.

4. 4

   Relationships gone quiet are surfaced

   Ranked by importance rather than by how long it has been, because the two are different questions.

5. 5

   Every organisation records the boundary

   Whether it also exists in the company CRM, and which system owns the relationship.

6. 6

   Anything in both with no owner is flagged

   That is the row where two teams eventually contradict each other in front of the customer.

1. 1

   Organisations and contacts, kept apart

   Because people move and the history should survive it.

   Copy

   In this Helix project, build me a lightweight CRM for a team whose
   relationships do not belong in the sales CRM.
   
   Two record types, and keep them genuinely separate.
   
   Organisations: name, type, website, region, size band, status, a named
   owner on our side, and a few attributes I will define, because what this
   team segments on is not what sales segments on.
   
   Contacts: name, role, email, phone, and a link to their organisation, as
   a relationship with a start and end date rather than a field. When
   somebody moves to a new company, the history stays with the person and
   the new relationship is added. Losing that history is the most common
   way this kind of app disappoints.
   
   Let one contact be linked to several organisations over time, and show
   the full history on the contact.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. And do not put any key or connection string in the
   code: if this needs to reach another system, tell me and I will create the
   connection in my workspace.

   Worth knowing. Modelling the person-to-organisation link as a dated relationship rather than a foreign key costs nothing now and is expensive to retrofit the first time somebody changes job.

2. 2

   The interaction log

   The part that makes it worth opening.

   Copy

   Add interactions, and make logging one take under thirty seconds.
   
   Each interaction: date, type (meeting, call, email, event, introduction,
   note), the organisation, which contacts were involved, who from our side,
   a summary, and any follow-up with an owner and a date.
   
   Append-only. Corrections are new entries referencing the earlier one.
   
   Let me paste an email or a set of notes and have you draft the fields for
   me to correct, because the reason interaction logs stay empty is that
   filling them in is tedious.
   
   Show the full history on both the organisation and every contact
   involved, and surface the ones that have gone quiet: organisations with
   no interaction for longer than a threshold I set, ranked by how important
   they are rather than how long it has been.

3. 3

   A pipeline with this team's stages

   Not a copy of the sales one.

   Copy

   Add a pipeline, and let this team define the stages.
   
   A pipeline record links to an organisation, has a stage, an owner, an
   expected value or outcome, an expected date, and a next step.
   
   Put the stages in a config file and seed them with something generic, but
   make it obvious they are meant to be replaced. A partnerships pipeline is
   not prospecting, qualification, proposal, closed. It is more like
   introduced, exploring, agreed in principle, contracted, live. A recruiting
   pipeline is different again.
   
   Copying the sales pipeline into a partnerships tool produces a pipeline
   nobody updates, because the stages do not describe anything that
   actually happens.
   
   Show it as a board, with anything that has not moved for a set period
   flagged.

4. 4

   Draw the boundary, and mean it

   The decision most of these apps skip.

   Copy

   Last, and most important: define the boundary with the company CRM.
   
   Add a field on every organisation recording whether it also exists in the
   company CRM, with the link if so, and which system owns the
   relationship.
   
   Then pick a rule and enforce it in the app. Either this system is
   authoritative for its own relationships and never writes to the CRM, or
   it reads the CRM for shared accounts and marks those records read-only
   here. Both are defensible. Having neither is not.
   
   Flag any organisation that exists in both with no owner recorded, because
   that is the row where two teams will eventually contradict each other in
   front of the customer.
   
   Then a handful of reports: interactions per organisation over time, the
   relationships gone quiet, pipeline by stage, and contacts whose email has
   bounced or whose role has changed, which is the maintenance nobody
   does.

   Worth knowing. The boundary rule is what stops this becoming a shadow CRM. It is a paragraph of policy and a field, and skipping it is how you end up with two truths.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <Salesforce>. Read shared accounts so the boundary is real, and mark those
   records read-only here rather than maintaining two truths.
   
   <Okta>. Authenticate every user, because contact records are personal data
   about people outside your company and an anonymous reader is not
   acceptable.
   
   <Gmail>. Log interactions from email without anybody retyping them, which
   is what keeps the history alive.
   
   <Google Calendar>. Pull meetings automatically so a logged interaction is
   the default rather than an act of discipline.
   
   <Slack>. Nudge an owner when an important relationship has gone quiet.
   
   <DocuSign>. Read whether the agreement behind a contracted relationship
   was actually signed.
   
   <Snowflake>. Land the interaction history, so a question like which
   relationships have gone quiet can be asked across years rather than
   months.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Contact records are personal data, so set Access Control before sharing and decide your retention rule early.

What it connects to

A lightweight CRM should read from the company CRM rather than compete with it, which is most of what these connections are for.

• Salesforce

  Read shared accounts so the boundary is real, and mark those records read-only here rather than maintaining two truths.

• Okta

  Authenticate every user, because contact records are personal data about people outside your company and an anonymous reader is not acceptable.

• Gmail

  Log interactions from email without anybody retyping them, which is what keeps the history alive.

• Google Calendar

  Pull meetings automatically so a logged interaction is the default rather than an act of discipline.

• Slack

  Nudge an owner when an important relationship has gone quiet.

• DocuSign

  Read whether the agreement behind a contracted relationship was actually signed.

• Snowflake

  Land the interaction history, so a question like which relationships have gone quiet can be asked across years rather than months.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides