Case Study Builder

Case Study Builder

Produces a Tiger Data "Community Member Spotlight" case study from a customer interview transcript. The output is a formatted .docx file with an embedded architecture diagram and a pull quote table.

---

Before You Start: Read Two Reference Files

Read both of these before writing a single word of the case study:

1. references/wabl-principles.md — Tiger Data writing standards. Every sentence must pass the WABL filter before the document ships. 2. references/case-study-format.md — The section structure, styling constants, and annotated guidance for each section of the document.

Also read the docx skill (find the docx SKILL.md in your available skills) before generating the .docx. The docx skill contains the exact docx-js patterns required to produce a valid Word document.

---

Step 0: No Fly List check

Fetch the No Fly List before doing any work. This requires Tiger Den:

get_marketing_reference(slug: "no-fly-list")

If Tiger Den is not available (get_marketing_reference fails or the tool is not found), warn the user: "No Fly List check skipped — Tiger Den is not connected. Verify manually that no restricted customers are referenced in the output before publishing." Then proceed.

If Tiger Den is available, load the returned names as a hard constraint: if the customer featured in this case study appears on the No Fly List, stop immediately and inform the user that this customer cannot be publicly referenced. If a No Fly List name appears in the transcript or other source materials, omit it from all outputs.

---

Step 1: Gather Inputs

Collect the following from the user's message and conversation history:

If the transcript is missing, ask for it before proceeding. Everything else is optional.

---

Step 2: Ask Two Clarifying Questions

Ask both at once. Do not start writing until you have answers.

Q1: First or third person? The case study can be written as the customer speaking in first person ("I built this because...") or as a third-person narrative ("Tacton's team built this because..."). The Tiger Data format supports both. First person is more personal and works well for technical founders. Third person is easier to edit and suits larger orgs with PR teams. Default to first person if the transcript is from a single technical founder.

Q2: Who is the primary reader? Options: (a) developers and engineers — emphasise architecture, data model, technical trade-offs; (b) technical buyers / VPs — emphasise ROI, team size, time-to-value; (c) general — balance both. Default to (a) if the transcript is highly technical.

---

Step 3: Extract from the Transcript

Read the full transcript carefully. Extract and organise the following before writing:

Company basics

• Company name, spokesperson name and title
• Industry, customer type, company size
• Product(s) being discussed

The problem

• What was painful or broken before Tiger Data?
• What did the old stack look like?
• Why was the old approach unsustainable?

Why Tiger Data

• How did they discover Tiger Data? (blog post, Reddit, colleague, etc.)
• What alternatives did they consider?
• What made Tiger Data the right choice? (specific criteria)
• What would self-hosting have cost them?

Architecture

• What are the named services, edge devices, brokers, APIs?
• What data flows where? In what order?
• What does Tiger Data specifically store? (data types, cadence)
• What other databases or platforms are in the stack, and what do they hold?
• How does data reach the customer-facing application?

Results and impact

• Quantified metrics: compression %, query speed, cost savings, uptime, time-to-deploy
• Customer impact stories: specific incidents, prevented failures, ROI moments
• Support / onboarding experience

Looking ahead

• Roadmap items the customer mentioned
• Scale targets, new data streams, future features

Direct quotes

• Collect every quote that is punchy, specific, and quotable. Prefer quotes that are

concrete ("we went from 4 minutes to half a second") over abstract ("it's been great").

• Note the exact words. You will clean up false starts and filler words but must not

change the meaning or put words in the customer's mouth.

• Capture the context, not just the quote. Read the lines before and after each

quote. A quote can be word-accurate but context-wrong — if the customer said something to explain why a problem is inherently complex (not to describe a failure of the old stack), framing it as a pre-Tiger Data symptom is a misrepresentation. Note what the speaker was responding to when they said it.

---

Step 4: Generate the Architecture Diagram

Write a Python script using matplotlib to produce the architecture diagram. Save it as a PNG in the current working directory as architecture.png.

Design guidance is in references/architecture-diagram-guide.md. The short version:

• White background, dot grid, monospace uppercase labels — no coloured zone fills
• Organise components into columns: Edge → Ingestion → Storage → Application
• Draw boxes with FancyBboxPatch: bold label only, no body text, compact height (~0.68 units)
• Tiger Data gets an orange border (2.5 lw), embedded logo badge, and a bold summary line
• Arrows with ax.annotate: omit labels unless the protocol is non-obvious
• Column headers as bold monospace text above each group
• figsize=(8, 4.5), coordinate system 0–16 × 0–9, save at 180 dpi

Run the script and confirm the PNG exists before moving to the next step.

---

Step 5: Write the Case Study .docx

Writing directive: Rewrite in the first person voice of the customer primarily pulling direct language from the transcript. Incorporate the Product Marketing Context from Tiger Den into the narrative.

Follow the structure in references/case-study-format.md exactly. Use the docx skill patterns for all formatting — never raw unicode bullets, never inline \n, and always set explicit page size (US Letter: 12240 x 15840 DXA).

About the Company & Team Lead with the customer problem — what pain does the end user of this product experience, and why does it go unsolved today? Then explain how the product solves it, with specific technical mechanisms. Team/founding story goes last and should be brief (1-2 sentences). This section should read like a problem brief for a developer audience, not a company bio.

The Challenge Describe the state of the world before Tiger Data. Be specific about what was slow, what cost too much, what was operationally painful. If there was a prior stack (InfluxDB, MongoDB, a Postgres cluster they self-hosted), name it and explain why it didn't scale.

Architecture-First Decision / Why Tiger Data Explain how the customer found Tiger Data, what alternatives they considered, what the specific decision criteria were, and why they chose managed over self-hosted. Include the discovery story if it's interesting (a Reddit comment, a blog post from 2018, a colleague recommendation). This is often the most differentiated section — it shows the customer made a deliberate technical choice, not just the default one.

The [Product] Stack (architecture section) Describe the full data flow in prose, naming every service. Then embed the architecture diagram. Follow the diagram with a caption. Do not just list components — explain what each one does and why it sits where it sits.

Results Lead with the most impressive metric. Then tell the impact stories from the transcript in order of emotional weight. Include at least one concrete before/after story (e.g. "$3K fix prevented $350K in downtime"). Put a pull quote block after any section where you have a strong direct quote that reinforces the message.

Looking Ahead Forward-looking only. No summary of what was just said. One or two paragraphs about what the customer plans to build next and how Tiger Data enables it.

Recommended Pull Quotes A table at the end. 5 rows. Columns: the quote itself (attributed, with " - Name, Title, Company"), and a recommended use note (hero, social, support section, etc.). All quotes must be direct quotes from the transcript, lightly cleaned for readability.

---

Step 6: WABL Review Pass

Before finalising, run the WABL filter from references/wabl-principles.md:

• [ ] Remove all em dashes. Replace with a regular hyphen-space ( - ) or restructure the sentence.
• [ ] Scan for AI slop: "seamlessly", "robust", "cutting-edge", "transformative",

"game-changing", "leverage", "harness the power of", "it's worth noting", "delve into"

• [ ] Confirm there is one clear message. If someone asks "what is this case study saying?"

the answer should be one sentence.

• [ ] Confirm the About section does not start with the spokesperson's name and job title.

It should start with the customer's problem.

• [ ] Confirm there is no recap conclusion. The Looking Ahead section should look forward,

not summarise what was said.

• [ ] Read one paragraph aloud. Does it sound like a confident engineer who built this?

If not, rewrite it.

---

Step 7: Validate and Deliver

Run the docx validation script from the docx skill against the output file:

python <path-to-docx-skill>/scripts/office/validate.py \
  <workspace>/{Company}_Case_Study.docx

All validations must pass before delivering. If they fail, unpack the XML, fix the issue, and repack using the docx skill's repair workflow.

Save the final file to the workspace/outputs directory and provide the user with a computer:// link.

---

Common Mistakes to Avoid

Starting the About section with the spokesperson. "I'm [Name], CTO of [Company]..." is a company bio opener. The reader does not yet know why they should care. Lead with the problem the customer faces, then introduce the product, then briefly note who built it.

Paraphrasing quotes instead of using them. If the transcript has "we went from nothing to first devices being installed in two months," use that. Don't write "they achieved rapid deployment." Direct quotes are the whole point of a case study.

Making up metrics. Only use numbers that appear explicitly in the transcript or prep doc. If a metric is approximate, say so ("close to 100 devices"). Never round up.

Skipping the discovery story. How the customer found Tiger Data is often the most interesting paragraph in the piece. A Reddit comment that led to a 2018 blog post that led to an architectural decision is a better story than "they evaluated several options."

Describing the architecture as a list. "We use X, Y, and Z" is forgettable. "X captures sensor readings and sends them to Y via MQTT. Y validates the device, applies calibration thresholds, and writes time-series data to Z" gives the reader a mental model they will actually remember.

Using a quote accurately but in the wrong frame. If the customer said "it'll never be a snap of the fingers" to explain why dashboard performance is inherently hard to optimise — not to describe a failure of the old stack — attributing it as evidence of pre-Tiger Data slowness is a misrepresentation even though the words are exact. Always check what question the speaker was answering when they said it.

Writing a generic Looking Ahead close. "Ready to expand their business at scale" says nothing. If the case study is about an architectural decision (single database, no split stack), the Looking Ahead section should land on what that decision means as the product scales — the specific complexity or cost problem that won't arise.

Architecture Diagram Guide

The architecture diagram is generated in Python using matplotlib and saved as a PNG, then embedded in the .docx. This guide covers layout principles, the colour palette, and the matplotlib patterns that produce clean, publication-quality output.

---

Visual Style: Clean Monospace (Current Standard)

The preferred diagram style is clean and minimal — white background, dot grid, monospace uppercase labels, no zone fill colours. Tiger Data is the visual hero: its box has an orange border and the Tiger Data logo badge embedded. Everything else is black borders on white.

This is the current Tiger Data standard, established in recent published case study diagrams.

---

Layout Principles

Column model: Organise every component into vertical column groups that mirror the data flow left to right. The standard columns are:

[ EDGE ] → [ INGESTION ] → [ STORAGE ] → [ APPLICATION ]

Adjust column names to match the customer's actual architecture:

• If there is no edge layer, start with "DATA SOURCES" or "INGEST"
• If storage splits into time-series and relational, label them separately
• If there is a BI/reporting layer, add it between STORAGE and APPLICATION

Column headers: Render column names as bold monospace uppercase text above the boxes. Do not use coloured zone backgrounds. The header labels alone identify each column.

Dot grid: Add a light dot grid behind everything for visual texture:

import numpy as np
for xi in np.arange(0.35, 16.0, 0.45):
    for yi in np.arange(0.35, 9.0, 0.45):
        ax.plot(xi, yi, ".", color="#DDEEFF", markersize=2.2, zorder=0)

Box design: Use FancyBboxPatch with rounded corners. Each box has:

• A bold monospace uppercase label, centred in the box
• A black border (1.3 lw) on white background
• No header bar, no body text lines — the label alone identifies the component

Keep box height compact (0.65–0.75 coordinate units). Tight boxes with no body text read more cleanly at the sizes used in a printed docx.

Tiger Data hero box: Give Tiger Data a visually distinct treatment:

• Orange border (2.5 lw, #F36B21) instead of black
• The Tiger Data circular badge logo embedded at top-left using OffsetImage + AnnotationBbox
• "TIGER DATA" bold label beside the logo
• A thin #DDDDDD divider line below the header area
• One or two bold summary lines centred below the divider, e.g. "SOURCE OF TRUTH /

FOR ALL FLEET DATA". Split long text across two lines to stay within the box.

from matplotlib.offsetbox import AnnotationBbox, OffsetImage
import matplotlib.image as mpimg

logo = mpimg.imread("tiger_logo.png")   # fetch from CDN or Figma if needed
imagebox = OffsetImage(logo, zoom=0.14)
ab = AnnotationBbox(imagebox, (logo_x, logo_y), frameon=False, zorder=6)
ax.add_artist(ab)

The Tiger Data badge SVG is available at: https://assets.tigerdata.com/timescale-web/brand/tiger-data/flat-logos/logo-badge-black.svg Convert to PNG with cairosvg before embedding.

Arrows: Use ax.annotate with arrowstyle="-|>". Arrow labels are optional. Omit labels unless the protocol is genuinely informative and non-obvious to the reader. Do not label arrows with generic data type names like "SQL", "HTTPS", "JSON", "time-series writes", or "dequeued messages" — the box labels and flow direction carry that meaning. Clean unlabelled arrows are preferred.

Canvas size: figsize=(8, 4.5) at 180 dpi produces a clean compact diagram. Use a 0–16 × 0–9 coordinate system regardless of figsize so proportions stay consistent. For complex architectures (5+ columns), use figsize=(10, 5.6).

---

Colour Palette

BLACK     = "#1A1A1A"   # box borders, column headers, box labels
ORANGE    = "#F36B21"   # Tiger Data hero box border, title accents
WHITE     = "#FFFFFF"   # box backgrounds, figure background
DARK_GRAY = "#555555"   # secondary text (diagram subtitle)
MID_GRAY  = "#AAAAAA"   # read-path arrows (lower visual weight than write paths)
DOT_COLOR = "#DDEEFF"   # dot grid
BORDER    = "#BBCCDD"   # outer border of the diagram canvas

---

Matplotlib Patterns

Setup

import matplotlib.pyplot as plt
import numpy as np
from matplotlib.patches import FancyBboxPatch
from matplotlib.offsetbox import AnnotationBbox, OffsetImage
import matplotlib.image as mpimg

BLACK = "#1A1A1A"; ORANGE = "#F36B21"; WHITE = "#FFFFFF"
DARK_GRAY = "#555555"; MID_GRAY = "#AAAAAA"; DOT_COLOR = "#DDEEFF"

fig, ax = plt.subplots(figsize=(8, 4.5))
fig.patch.set_facecolor(WHITE)
ax.set_facecolor(WHITE)
ax.set_xlim(0, 16)
ax.set_ylim(0, 9)
ax.axis("off")

Label-only box helper

BOX_H = 0.68   # standard box height for label-only boxes

def mbox(ax, x, y, w, h, title, is_tiger=False):
    lw = 2.5 if is_tiger else 1.3
    ec = ORANGE if is_tiger else BLACK
    ax.add_patch(FancyBboxPatch(
        (x, y), w, h,
        boxstyle="round,pad=0,rounding_size=0.14",
        linewidth=lw, edgecolor=ec, facecolor=WHITE, zorder=3))
    if title:
        ax.text(x + w/2, y + h/2, title,
                ha="center", va="center", fontsize=11, fontweight="bold",
                fontfamily="monospace", color=BLACK, zorder=5)

Arrow helper (no label by default)

def arr(ax, x1, y1, x2, y2, label="", color=BLACK, rad=0.0):
    ax.annotate("", xy=(x2, y2), xytext=(x1, y1),
                arrowprops=dict(arrowstyle="-|>", color=color, lw=1.2,
                                connectionstyle=f"arc3,rad={rad}",
                                mutation_scale=9),
                zorder=6)
    if label:
        mx, my = (x1+x2)/2, (y1+y2)/2
        ax.text(mx, my+0.13, label, ha="center", va="bottom",
                fontsize=8, fontfamily="monospace", color=color, zorder=7)

Save

plt.tight_layout(pad=0.10)
plt.savefig("architecture.png", dpi=180, bbox_inches="tight", facecolor=WHITE)

---

What to Include in Each Box

In the clean label-only style, boxes are identified by name only. Choose names that are self-explanatory to a developer reader:

• Edge: The device or sensor name (e.g. "BESS UNITS", "EDGE NODES", "SENSORS")
• Ingestion: The queue or broker name (e.g. "AWS SQS QUEUE", "MQTT BROKER")

and the processing layer (e.g. "AWS EKS", "INGESTION SERVICE")

• Tiger Data box: Use "TIGER DATA" as the label, plus a one or two-line bold summary

below the divider. The summary should name the role, not list features.

• Other storage: Name the service (e.g. "S3 TIERED STORAGE", "POSTGRES")
• Application: Name the consumer (e.g. "CUSTOMER DASHBOARDS", "FLEET OPTIMIZER",

"TSO/DSO REPORTING")

---

Common Mistakes

Adding body text to boxes. Bullet-point descriptions inside boxes clutter the diagram and become unreadable at print size. The box label is enough. Put detail in the prose narrative in the Stack section of the case study instead.

Labelling arrows with generic data types. "SQL", "HTTPS", "JSON", and "time-series writes" add visual noise without informing the reader. Omit these labels; the directional flow and box labels communicate the relationship.

Using coloured zone backgrounds. Zone fills make the diagram look like a slide deck. Column headers above the boxes provide the same orientation without the clutter.

Tiger Data not visually distinct. The orange border and embedded logo are what make Tiger Data stand out. Do not reduce the border weight or omit the logo.

Text overflowing boxes at compact figsize. At figsize=(8, 4.5), long labels like "SOURCE OF TRUTH FOR ALL FLEET DATA" overflow the box. Split across two lines. For application box labels longer than ~18 monospace characters, widen the box slightly (x position - 0.12, w + 0.25) rather than reducing font size.

Unlabelled columns. Without column headers, the diagram loses orientation. Always render "EDGE", "INGESTION", "STORAGE", "APPLICATION" (or equivalents) as bold monospace text above each column group.

Tiger Data Case Study Format Reference

Document Structure

Every Tiger Data "Community Member Spotlight" case study follows this section order. Do not add or remove sections. Each section has a specific job.

1. Title block
2. Lede (italic series intro + speaker intro)
3. About the Company & Team
4. The Challenge
5. Why Tiger Data / Architecture-First Decision
6. The [Product] Stack  ← architecture section with diagram
7. Results / What We've Seen
8. Looking Ahead
9. Recommended Pull Quotes  ← table, 5 quotes

---

Section-by-Section Guide

1. Title Block

Format: How [Customer] [achieved outcome] with Tiger Data

Good titles name a specific result or frame a specific tension. They do not name-drop features or use vague language.

Excerpt/subtitle: One sentence. Name the key metric. Appears under the title in the Ghost CMS format and in social previews. Example:

"How a 5-person startup chose Tiger Data before writing production code, then shipped

100+ devices to manufacturing shop floors in under 60 days."

---

2. Lede (Italic Intro)

One or two italic paragraphs. The series boilerplate paragraph is optional — omit it if the case study is not being published as part of the "Community Member Spotlight" series, or if the user has provided a direct factual subtitle instead.

Series boilerplate (optional):

*This is an installment of our "Community Member Spotlight" series, in which we invite

our customers to share their work, spotlight their success, and inspire others with new

ways to use technology to solve problems.*

Speaker / result intro (required): Name, title, company, one sentence about what they built or migrated, and the one-line result. This is the hook that earns the reader's attention. When the series boilerplate is omitted, this paragraph also carries the orienting function — make sure it names the company, spokesperson, and headline outcome.

Example (no series boilerplate):

*[Company], a [product description], migrated its [workload] from [old stack] to Tiger

Data, [headline metric]. In this piece, [Company] [Title] [Name] shares how the team

evaluated the move and managed the migration.*

---

3. About the Company & Team

Job: Establish the customer problem and why it goes unsolved today. Then explain the product. Team details go last and briefly.

Structure (in this order): 1. The gap in the market — what do small/underserved customers lack access to? 2. Why that gap exists (cost, complexity, vendor requirements, compliance risk) 3. What the product does about it (concrete technical mechanism, not marketing language) 4. A specific quantified result that happened as a consequence (optional but powerful) 5. One sentence on the team: who built it and at what scale

Multi-segment customers: When the product serves multiple distinct customer types (e.g. agriculture, logistics, EV charging), open with a paragraph for each customer segment's specific pain before introducing the product. Each segment paragraph should name the specific problem that segment faces and why it goes unsolved — not a generic "energy is expensive" statement, but the specific mechanism (e.g. DSO demand spike penalties, grid connection upgrade timelines). The product introduction then arrives as the common solution to the problems just described.

Example structure for a multi-segment About:

Para 1: [Segment A] customer pain (specific mechanism, e.g. demand spikes → DSO tariff penalties)

Para 2: [Segment B] customer pain (specific mechanism, e.g. short peak draws during loading windows)

Para 3: [Customer] solution — what it does for all customer types

Para 4: Secondary business model layer, if applicable (e.g. market trading optimizer)

Para 5: Company scale, funding, team size

What this section is NOT:

• A company bio ("Company X was founded in 2022 by...")
• A product feature list
• A first-person intro ("I'm [Name], CTO of...")

---

4. The Challenge

Job: Show the state of the world before Tiger Data. Make the reader feel the pain.

Cover:

• What the old stack was (name it)
• What specifically broke or didn't scale (slow ingestion, ballooning storage, no retention)
• What the operational cost was (human toil, money, risk)
• Why it was becoming unsustainable

Use bullet points only for discrete, parallel pain points. Otherwise write in prose.

---

5. Why Tiger Data / Architecture-First Decision

Job: Show the customer made a deliberate, informed technical choice.

Cover:

• How they discovered Tiger Data (the more specific and unexpected, the better)
• What alternatives they evaluated and why those didn't fit
• The specific decision criteria (unified stack, managed service, compliance, cost)
• Why they chose Tiger Cloud over self-hosting

This section often contains the most differentiated content in the piece. A customer who found Tiger Data via a Reddit comment linking to a 2018 blog post about time-series trade-offs is a better story than "after evaluating several options." Use the real story.

---

6. The [Product] Stack

Job: Give the reader a clear mental model of how the system works end-to-end.

Structure: 1. Describe the full data flow in prose — from data source to end user 2. Name every service. Explain what each does and why it sits where it sits. 3. Embed the architecture diagram (PNG, ~660px wide, centered) 4. Caption below the diagram (italic, gray)

Write the data flow as a narrative, not a component inventory:

"The edge device captures power and vibration readings every 10 seconds and sends them

to a Mosquitto MQTT broker over TLS. The Sindri ingestion service picks up each message,

validates the device identity against Supabase, applies calibration thresholds, and

writes the time-series measurements to Tiger Data."

Not:

"Components: edge device, MQTT broker, ingestion service, Tiger Data, Supabase."

---

7. Results / What We've Seen

Job: Deliver the concrete value. Lead with the biggest number. Follow with stories.

Lead with the headline metric (compression ratio, cost savings, time-to-deploy, query speed). Then tell impact stories in order of emotional weight. End with a support or team experience anecdote if there is one.

Pull quote blocks: Place a pull quote block after any subsection where you have a strong direct quote. Use the styled left-border block (orange accent, navy text, ~13pt).

Result subsections (H3): Use subsections for distinct result categories. Example:

• "Zero to Production in 60 Days"
• "$350,000 in Prevented Downtime"
• "Support That Builds Trust"

---

8. Looking Ahead

Job: Show this is the beginning of the story, not the end.

One or two paragraphs. Forward-looking only. What will the customer build next? What scale are they targeting? What does Tiger Data enable that wasn't possible before?

Do NOT summarise what was said in previous sections. Do NOT start with "In conclusion" or "Overall". Do NOT write a second conclusion.

Architectural payoff close: If the case study's central proof point is an architectural decision (e.g. choosing a single Postgres database over a split time-series + OLAP stack), the Looking Ahead section is the right place to land that payoff. State the growth targets, then close on what the architecture decision means as the fleet or data volume scales — specifically the complexity or cost problems that won't arise because of the choice made.

Example:

*[Customer] is targeting [growth target] — [relative scale, e.g. "roughly seven times

today's fleet"] — with [new product lines] in development. The decision that compounds

as they scale isn't the [headline metric]. It's that everything runs on a single

[database]: the [system A], the [system B], the [system C], the full historical record.

No split architecture to maintain, no query paths to reconcile as the [fleet/dataset]

grows. The data model doesn't change — it just gets bigger.*

---

9. Recommended Pull Quotes

A table with 5 rows. Two columns:

• Quote: the direct quote, attributed as "[quote]" - [Name], [Title], [Company]
• Recommended use: one-line note on where this quote works best

All quotes must be real words from the transcript. Light cleanup is fine (remove filler like "like, you know, uh") but do not change meaning or add words.

---

Styling Constants (docx-js)

const NAVY   = "1A3D6E";   // section headings
const ORANGE = "F36B21";   // pull quote left border, Tiger Data box accent
const BLUE   = "2D6EA8";   // H2 headings
const LTBLUE = "EBF4FB";   // table row alternating background
const RULE   = "D8E9F5";   // horizontal rules, table borders
const WHITE  = "FFFFFF";

Page size: US Letter (12240 x 15840 DXA), 1-inch margins (1260 DXA all sides) Body font: Arial, 22 half-points (11pt) H1: 38 half-points, bold, NAVY H2: 26 half-points, bold, BLUE H3: 23 half-points, bold, NAVY Pull quote: 25 half-points, bold, NAVY, left border ORANGE THICK 24

Header: series label + company name (gray, 16 half-points), bottom border RULE Footer: tigerdata.com right-aligned (gray, 16 half-points), top border RULE

---

Worked Examples

Tacton / Sense Manufacturing — good reference for:

• About section that leads with customer problem, not company bio (see: "Most machine

monitoring tools are built for factories with hundreds of machines...")

• Architecture section written as prose narrative with a matplotlib diagram
• Results section with a concrete before/after story ($350K in prevented downtime)
• Looking Ahead that doesn't summarise, just looks forward
• Pull quote table with placement guidance

As additional case studies are published on tigerdata.com, add them here with a link to the published post and a note on what pattern they illustrate best.

Tiger Data WABL Writing Principles

WABL: Would Anything of Value Be Lost if this were removed?

Often the answer is no. When the answer is no, remove it. This is not about making things shorter for the sake of it — it is about making work stronger by removing what dilutes it.

---

Universal Rules (every asset type)

• No em dashes. Full stop. Replace with a regular hyphen ( - ) or restructure the sentence.
• No AI slop. Flag and remove: "seamlessly", "robust", "cutting-edge", "transformative",

"game-changing", "leverage", "harness the power of", "in today's fast-paced", "it's worth noting", "delve into"

• One clear message. If someone asks "what is this piece saying?" and the answer is more

than one sentence, simplify.

• Does it sound human? Would a confident engineer who has actually built this write it

this way? If not, rewrite it.

• No filler intros. Never start with "In this post, we will explore..." or "In today's

landscape..." or a paragraph that restates what the title already said.

• No recap conclusions. Do not end by summarising what you just said. Reinforce the one

message, give one next step, stop.

---

For Case Studies Specifically

Introduction (lede): Must answer in the first 5-7 sentences: Who is this customer? What did they build? What is the one result worth reading for? Do not start with the company description — start with the tension or the result.

Each section: Must serve the main message. If a section exists only to add length, cut it.

Conclusion / Looking Ahead: One clear direction. What will the customer build next and why does Tiger Data enable it? Never two conclusions. Never a summary.

---

WABL Checklist for Case Studies

Before finalising, confirm each item:

• [ ] Em dashes removed (search for — and replace)
• [ ] AI slop phrases removed or rewritten
• [ ] About section leads with the customer problem, not the spokesperson bio
• [ ] Every section has a reason to exist — ask "would anything of value be lost if this

section were removed?"

• [ ] Pull quotes are direct quotes from the transcript — not paraphrases
• [ ] Conclusion looks forward, not backward
• [ ] Read one paragraph aloud — does it sound like a confident engineer?
• [ ] Is there one clear message? Can you say it in one sentence?

---

What Good Looks Like: Before / After

Before (fails WABL):

"In today's competitive manufacturing landscape, organizations are increasingly looking

for solutions that can help them manage their growing operational data needs. Tacton, a

robust and cutting-edge IoT platform, offers a seamless experience for teams who need to

handle high-ingest workloads from industrial sensor data at scale."

After (passes WABL):

"Most machine monitoring tools are built for factories with hundreds of machines and

dedicated IT teams. They require 30-device minimums, deep PLC integrations, and pricing

structures that make sense if you're running a 500-person operation. For a shop with 20

CNC machines and an owner tracking jobs on a whiteboard, they're not an option."

The before version says nothing specific. The after version names the real problem — who it excludes and why — in concrete terms a developer immediately understands.