MimicScribe

Getting Better Results

The AI assistant is only as good as the context you give it. Two minutes of setup — filling out your role and goals, and adding a reference document or two — changes the output from generic meeting notes to a briefing that understands what you’re actually trying to accomplish.

This page shows how to do both well, with fleshed-out examples you can adapt.

Your Context

Settings > Your Context — a free-form description of who you are and what you do. It’s included in nearly every AI request: summaries, assistant briefings, dictation refinement, voice instructions. Writing a good one compounds across every feature.

Cover three things, in order of importance:

  1. Who you are and what your job is. Title, team, the kinds of meetings you run, and what success looks like this quarter. Be concrete — “Solo dev building custom internal tools for 20–200 person teams” beats “I’m a freelance engineer.”
  2. What meetings you typically run. A short list — renewals, QBRs, implementation kickoffs, 1:1s. The assistant uses this to figure out what’s signal versus noise.
  3. What you want the assistant to catch (and what to ignore). Action items, competitor mentions, exec changes, expansion signals, ambiguous commitments. Telling it what not to care about is as useful as telling it what matters.

Example: Custom software builder

I'm Alex Rivera. I build custom internal tools — lightweight CRMs,
workflow apps, and operations dashboards — for 20–200 person teams who've
outgrown spreadsheets but don't fit the generic SaaS mold. I run a solo
practice with one contractor and take on 4–6 engagements at a time.
Typical project: $15K–$60K, 4–10 weeks.

My typical meetings:
- Discovery calls with prospects where I'm mapping their actual workflow
  — what tools they glue together today, what breaks, what they've tried
  to fix and abandoned
- Scoping sessions after a verbal yes, narrowing the build to a first
  shippable version and cutting the rest into a phase two
- Weekly check-ins with active clients — demo, feedback, priority
  shuffling, and catching scope drift before it becomes a problem
- Handoff sessions where I walk the client's team through the app, often
  training a non-technical owner who'll run it day to day

What I need from meeting summaries:
- Concrete workflow details: the steps people take, the fields they
  track, the handoffs between roles. This is what I build from.
- Flag anything that sounds like a pre-existing system I should integrate
  with (HubSpot, QuickBooks, Airtable, Google Sheets) rather than replace
- Capture scope-creep signals: "could we also…", "while you're in
  there…", new stakeholders introduced mid-project
- Note who actually makes decisions and who just shows up — the loudest
  opinion in the meeting isn't always the approver
- Surface pain points the client mentions in passing — those are often
  the real reason they're hiring me, even if they lead with something
  else

I care less about feature wishlists and more about the workflow
underneath them. If someone says "we want a dashboard," I want to know
what decision they're trying to make with it. Flag vague asks as
ambiguous rather than treating them as requirements.

For shorter alternatives tied to specific workflows (dictation profiles, summary templates, per-meeting templates), see Customizing for Use Cases.

Reference Documents

Settings > Your Context > Reference Documents — upload URLs or files that the AI can pull from during meetings. Good reference documents are the kind of thing you’d hand a new hire to read — not marketing copy.

Strong candidates:

  • Competitive positioning notes (covered in detail below)
  • Pricing cheat sheets and discount authority rules
  • Objection handlers and common FAQs
  • Product roadmap summaries or integration compatibility matrices
  • Implementation playbooks or onboarding checklists
  • Company wiki pages — team structure, terminology, internal acronyms

A good reference doc has three parts: where the product wins, where it doesn’t compete (honesty helps — it keeps the assistant from hallucinating capabilities you don’t have), and common objections with responses.

Example: Build vs. buy framework

Hypothetical practice: “Rivera Workflow Tools,” a solo-dev shop that builds custom internal tools — lightweight CRMs, ops dashboards, and workflow apps — for 20–200 person teams. $15K–$60K per project, 4–10 weeks. Best fit: teams whose process is specific enough that off-the-shelf SaaS forces expensive workarounds.

# Rivera Workflow Tools — Build vs. Buy Framework

## vs Salesforce / HubSpot (generic CRM)

When custom wins:
- The client's process has 3+ steps that don't fit the "lead →
  opportunity → close" shape. Forcing it into Salesforce means custom
  objects, flows, and a 6-month admin tail.
- Small team (under 15 sales or ops users). Per-seat SaaS plus
  implementation cost exceeds a one-time build within ~18 months.
- They've already tried HubSpot or Salesforce and abandoned it —
  usually a sign the workflow is specific enough to justify custom.

When I recommend off-the-shelf instead:
- Standard outbound sales motion. HubSpot or Pipedrive will ship in a
  week and handle it better than anything I'd build.
- Team growing past ~40 seats in the next year. At that scale the
  maintenance story for a custom build gets expensive, and the SaaS
  ecosystem (integrations, hiring pool) starts to pay off.
- Compliance-heavy contexts (regulated finance, healthcare with PHI).
  I don't build SOC 2 Type II into a $40K engagement.

Common objections:
- "Won't this be a maintenance burden?" → True if I over-engineer. I
  build on boring stacks (Postgres, a thin server, a standard auth
  provider) so any competent contractor can maintain it. Three months
  of post-ship support is included.
- "What if you disappear?" → Source lives in their GitHub, deployed
  to their cloud account, documented for handoff. Walk through the
  handoff doc from the Martin & Co engagement as proof.

## vs Airtable / Notion / Monday (no-code)

When custom wins:
- The workflow has real branching logic or calculations — pricing
  engines, approval chains, anything where "if this, then that"
  starts stacking. No-code hits a wall here fast.
- Integrations beyond the native connectors. Most clients need at
  least one API that Zapier doesn't cover cleanly.
- Performance at scale. Airtable over ~10K rows in a relational shape
  gets painful; Notion is slower still.

When I recommend no-code instead:
- Internal task tracking, project management, content calendars.
  Notion and Airtable are genuinely better than anything I'd build.
- Prototype phase. If the workflow isn't settled, build it in
  Airtable first, run it for 3 months, then I'll migrate it.

Common objections:
- "Our team already lives in Notion" → I can build tooling that reads
  from and writes to Notion via their API. Reference the Helios
  project — we kept task tracking in Notion and built a custom
  pipeline view on top.
- "Isn't no-code cheaper?" → Licensing is cheaper. Total cost
  including workaround overhead and data extraction when you outgrow
  it usually isn't.

## vs Building In-House

When I'm the better fit:
- They don't have a dedicated engineer, or their engineers are booked
  on the core product. Internal tools always lose that fight.
- Project is well-scoped, 4–10 weeks. Hiring a contractor for that
  window is faster and cheaper than pulling a full-timer.

When I recommend hiring instead:
- The tool becomes core to their business (the thing their customers
  touch). Long-term ownership matters more than time-to-first-version.
- They need ongoing iteration with weekly priority shifts. A retained
  contractor works, but a full-timer is usually a better match
  long-term.

## Things I'm honest about

- I don't do mobile apps. If they need native iOS or Android, I point
  them to specialists and scope the build to web-only.
- I don't do ML / AI features beyond API calls to OpenAI or Anthropic.
  Anything requiring a trained model is outside scope.
- Ongoing support is project-based, not retainer by default. If they
  want a retainer I'll quote it, but a fresh engagement every 6 months
  usually keeps scope more honest.

Why this works

During a discovery call, when the prospect says “we tried Salesforce and it was too much,” the assistant pulls the relevant section and surfaces diagnostic questions grounded in your framework — whether their workflow actually justifies a custom build, or whether Pipedrive would serve them better. The “Things I’m honest about” section keeps the assistant from quoting you on capabilities (mobile, ML) you don’t deliver.

Next steps