I do product strategy and product marketing for early-stage startups, mostly with technical products like databases and developer tools. A lot of the work is helping dial in their roadmap, messaging, and positioning. But I also help create finished collateral from those foundations, such as one-pagers, pitch decks, and battlecards.

One of the biggest challenges is keeping everything in sync. Make a change to the messaging, for example, and I may need to change every one-pager, every pitch deck, and every battlecard. AI agents like Claude Code can quickly make such changes to plain text, such as markdown files or wiki pages. But editing PowerPoint files or Canva designs takes longer, and there’s no easy way to verify the result without opening and checking each file.

This got me thinking about static site generators such as Hugo, which build finished web pages from plain text content. Could presentations and collateral work in a similar way? Could I instead build these assets from declarative source files? I decided to find out.

Exploring the Options

We’ve seen a wave of new AI slide tools over the past few years, which have changed the way slides and collateral are made. Gamma, for example, lets you build a deck through prompts rather than clicking around in a UI. NotebookLM goes further, using image generation models to produce high-fidelity slides and infographics. And Claude Design can build a complete design system, helping you create slides, one-pagers, and mockups with a common look and feel.

However, none of these tools suited my use case, as they work from prompts that can be interpreted differently each time, rather than from source files like Hugo does. I needed a tool that could:

1. Generate slides from source files that I could track in Git.

2. Produce editable output that clients could open in their existing tools.

3. Match a client’s existing design system exactly.

That narrowed the search to markdown presentation tools and template engines.

Markdown Presentation Tools

Marp and Slidev are examples of markdown presentation tools, which work in a similar way to Hugo. You write slides as markdown files, which are then rendered into HTML and exported to PDF or PowerPoint. You can customize the design system of each with CSS, and both have open-source themes to start from, such as Neversink for Slidev. Both are popular with engineers and engineering use cases, with support for code syntax highlighting and Mermaid diagrams.

Slidev in particular looked promising, given its extensible component model based on Vue. I implemented my tycoworks color scheme and slide layouts in CSS, and built some Vue components for things I commonly use, such as timeline views and comparison matrices.

The result looked great, but there was a big problem: neither Slidev nor Marp export editable PowerPoint files. Both render each slide to an image using a headless browser, rather than implementing the design as native PowerPoint objects, and so I had to keep searching.

Template Engines

Template engines work by filling in placeholders within PowerPoint files, such as {title} typed into the title slide. It’s a tried and tested approach so there are plenty of options, from open-source libraries like docxtemplater through to commercial products like Conga Composer. The big advantage is that you reuse your existing slides, so these tools are quick to set up and the output is editable and on brand by design.

I tried docxtemplater, since it’s open core, has been around for over a decade, and supports Word and Excel as well as PowerPoint. I first added placeholders to my slides, such as {title}, {name}, and {jobtitle} in the case of the opening slide. I could then write new presentations as JSON files of key-value pairs, which docxtemplater merges into the slides.

It was simple and my slides looked perfect, but this simplicity was also a limitation. While template engines work well for plain text values like {title}, swapping in whole blocks of text, with any mix of bullets, paragraphs, and formatting, is harder. With docxtemplater, you have to slice content into separate text runs to apply different formatting, which can make the JSON unwieldy and hard to diff versus markdown.

Filling in the Gap

Both approaches had their strengths. Slidev let me write slides in markdown, whereas docxtemplater gave me native slides I could edit. But I needed a tool that could do both and more, so I set out to build one.

My first attempt was similar to Slidev, but with its own flexbox-based DSL instead of raw CSS and Vue. You defined design tokens, layouts, and components with TypeScript, then wrote the slides themselves in markdown. Under the hood, it rendered each slide as HTML, measured the position and size of every object, then wrote an editable PowerPoint file with pptxgenjs.

However, I eventually abandoned this idea due to differences between HTML and PowerPoint rendering. Slight variations in glyph widths, line heights, and text wrapping meant a line could break differently in PowerPoint, throwing off the position of everything around it. I’d also need to support a huge amount of HTML and PowerPoint for it to be useful, further confirming it was the wrong approach.

So I kept the markdown layer but replaced the renderer underneath with a template engine. The result was tycoslide.

How It Works

tycoslide is a template engine with a markdown front end. You start by wrapping your existing .pptx file as a ‘theme’ — an npm package that describes layouts, colors, and fonts — which you can version and manage like code. You then write slides in GitHub-flavored markdown, including code blocks and Mermaid diagrams, which tycoslide turns into editable PowerPoint files.

Rather than putting placeholders like {title} directly into the template, tycoslide uses a separate manifest to describe the available text, tables, and images per layout. Under the hood, it uses pptx-automizer to fill the template, remark to parse the markdown, and Shiki to highlight code. It also packages each theme as an agent skill.

Want to try it out? The guide walks you through setting tycoslide up on your template, including packaging it as a skill for your team. Or if you just want to see it in action, the tycoworks theme and its two example decks are a good place to start.

Conclusion

So, can slides be built from source files? For me, yes. Most of my decks are now themes and markdown files in Git, which Claude Code can update in bulk when things change. And because the theme enforces the design, I don’t need to visually check each change, so I can work entirely through pull requests like code.

Where could it go from here? There are some near-term features I need, like supporting charts and multiple PowerPoint files per theme, so I can build one-pagers, pitch decks, and battlecards from the same theme. I could also add a template system, so that common content like taglines could be injected instead of duplicated (a template engine inside a template engine? Meta).

But my bet is to keep tycoslide simple and build more into the agent layer instead. Skills have become a common standard for giving agents new capabilities, replacing a lot of custom code. Frontier LLMs are becoming cheaper and more capable every week. And new decision models like Jev and Laya could detect outdated messaging or banned terms in milliseconds, making them fast and cheap enough to run on every change.

If you’ve also been thinking about this, I’d love to hear from you. What have you tried? Did tycoslide work for you? Drop me a line here or at chris@tycoworks.com.

Share tycoworks

I wanted a better way, and so I’ve started working on a new project: tycostream. It turns Materialize views into real-time GraphQL APIs, so you can quickly build live, type-safe apps, agents, and dashboards without needing custom infrastructure or glue code.

It would need a lot more work for production use, but the core functionality is ready for feedback. Let’s take a look.

How It Works

The design is inspired by view servers such as Finos Vuu or the Genesis Data Server, which are common components of financial markets applications. These components excel at streaming ticking prices, positions, and orders to thousands of connected UIs with fine-grained permissions and filtering. I wanted to build something similar but using open standards: GraphQL for the API and Postgres wire protocol for the database connection.

With that in mind, tycostream works a bit like Hasura, but for streaming databases (currently Materialize). There are two key features:

• Subscriptions stream typed, real-time updates to clients, with optional where clauses for filtering.

• Triggers register webhooks that fire when data meets specific conditions, for alerting, workflow automation, or integrating with external systems.

You define the views to expose, and tycostream generates GraphQL subscriptions and mutations from their schema. For example, given a trades table like this:

CREATE TABLE trades (
  id INT,
  instrument_id INT,
  side TEXT,
  quantity INT,
  price NUMERIC,
  executed_at TIMESTAMP
);

tycostream generates a GraphQL API like this:

type Subscription {
  trades(where: tradesExpression): tradesUpdate!
}

type Mutation {
  create_trades_trigger(input: tradesTriggerInput!): Trigger!
  delete_trades_trigger(name: String!): Trigger!
}

type Query {
  trades_triggers: [Trigger!]!
  trades_trigger(name: String!): Trigger
}

type tradesUpdate {
  operation: RowOperation!
  data: trades
  fields: [String!]!
}

type trades {
  id: Int!
  instrument_id: Int
  side: side
  quantity: Int
  price: Float
  executed_at: String
}

type Trigger {
  name: String!
  webhook: String!
  fire: String!
  clear: String
}

enum RowOperation {
  INSERT
  UPDATE
  DELETE
}

enum side {
  buy
  sell
}

input tradesTriggerInput {
  name: String!
  webhook: String!
  fire: tradesExpression!
  clear: tradesExpression
}

input tradesExpression {
  id: IntComparison
  instrument_id: IntComparison
  side: sideComparison
  quantity: IntComparison
  price: FloatComparison
  executed_at: StringComparison
  _and: [tradesExpression!]
  _or: [tradesExpression!]
  _not: tradesExpression
}

input IntComparison {
  _eq: Int
  _neq: Int
  _gt: Int
  _lt: Int
  _gte: Int
  _lte: Int
  _in: [Int!]
  _nin: [Int!]
  _is_null: Boolean
}

input FloatComparison {
  _eq: Float
  _neq: Float
  _gt: Float
  _lt: Float
  _gte: Float
  _lte: Float
  _in: [Float!]
  _nin: [Float!]
  _is_null: Boolean
}

input StringComparison {
  _eq: String
  _neq: String
  _in: [String!]
  _nin: [String!]
  _is_null: Boolean
}

input sideComparison {
  _eq: side
  _neq: side
  _in: [side!]
  _nin: [side!]
  _is_null: Boolean
}

Under The Hood

tycostream is built with TypeScript using NestJS, RxJS, and Apollo Server. NestJS provides database connectivity and WebSocket support out of the box, along with modules for authentication, observability, and deployment for later down the line. RxJS handles the reactive stream processing, and Apollo Server provides the GraphQL layer with an interactive explorer for testing queries.

The project is architected into three core modules:

• A database module that manages Materialize connections and parses the data stream

• A view module that maintains an in-memory cache and handles client-side filtering

• An api module that generates the GraphQL schema from view definitions

tycostream lazily instantiates a cache and Materialize connection for each view exposed over the API. When the first request for a given view comes in, tycostream opens a new connection, caches incoming updates, and streams them to the client. Additional requests for the same view are first served a snapshot from the cache, then connected to a live stream of inserts, updates, and deletes. When requests have where clauses, tycostream compiles them into JavaScript functions to filter each row as it streams through.

Integration Testing

The project includes integration test infrastructure built on Testcontainers, Apollo Client, and Express. You define a test scenario as:

1. A sequence of database operations for tycostream to process

2. The number of clients to spin up and how they should interact with tycostream’s subscriptions and triggers

3. The expected state each client should see at the end

For example, a test with one client subscribed to positions and a loss alert trigger looks like this:

const testEnv = await TestEnvironment.create({
  appPort: 4001,
  schemaPath: 'test/schema.yaml',
});

const client = testEnv.createClient('positions-client');

await client.subscribe('positions', {
  query: `subscription { positions { operation data { id quantity } } }`,
  expectedState: new Map([[1, { id: 1, quantity: 100 }]]),
});

await client.trigger('loss-alert', {
  query: `mutation($url: String!) { create_trigger(name: "loss", view: "positions", ...) }`,
  expectedEvents: [{ event_type: 'FIRE', data: { id: 1 } }],
});

await testEnv.waitForCompletion();

The test passes when all clients converge to their expected state, and fails if it times out or the liveness check detects that data has stopped flowing.

Why This Matters

In Part 1, I asked whether we’d see business logic pulled out of applications and centralized in streaming databases. Turns out there’s already a name for this pattern: the streaming data mesh. The idea is that individual teams can publish well-defined, versioned “data products” that anyone can use, thereby creating internal APIs for live data.

I believe streaming databases like Materialize are the unlock for this pattern. They let developers join and transform live data using standard SQL, making it much easier to build scalable, real-time applications. And as demand for streaming databases grows, I expect we’ll need an ecosystem of tools around them — API layers for access, entitlements for security, and ways to trigger logic on certain conditions. This is where tycostream fits in.

Imagine vibe coding a positions dashboard in Retool. Under the hood, it’s a simple case of connecting workflows and UI elements to live data products via GraphQL, making streaming applications as easy to build as CRUD.

Try It Out

Want to see tycostream in action? There’s a positions dashboard demo in the repo you can spin up locally with a single command. It uses a lightweight simulator to generate trades and market data, a Materialize emulator instance to calculate real-time positions as materialized views, and tycostream subscriptions to stream everything to the frontend. There’s also an alerts panel showing when realized losses exceed a threshold, implemented via tycostream triggers.

If you’re building real-time applications with SQL and GraphQL, I’d love to hear from you. What problems are you solving? What would make this useful for your use case? Drop me a line here or at chris@tycoworks.com.

I used to work at Genesis, a platform for rapidly building financial markets applications. The core idea behind the platform is simple: make it easier to build complex, real-time applications through familiar concepts like database tables and views. For example, to build a real-time view of stock positions, you could join a trades table with a market data table, calculate positions using an SQL-like SUM() function, and serve that to a UI with minimal code.

These ideas have been around for a while in capital markets, and are now becoming common in real-time data processing. Products like Materialize and RisingWave, for example, let developers build live views over streaming data with Postgres-compatible SQL, kept up to date with millisecond-level latency. These ‘streaming databases‘ blur the line between databases and stream processors, and are gaining traction in areas like capital markets, manufacturing, and e-commerce.

This got me thinking recently about the trading desk of the future — what role might these technologies play, especially in the parts that don’t need ultra-low latency? Will we see business logic pulled out of applications and centralized in tools like these? Could they power a real-time financial markets application?

To explore this, I set out to build a positions view powered by a streaming database, to see what’s possible and where the friction lies.

Designing the Application

For the UI, I wanted a simple grid showing live positions, market value, and theoretical P&L per instrument. It’s a small scope, but it covers many of the things you’d expect in a financial markets application, such as live and static data, real-time calculations, and ticking frontend updates. On the backend, I wanted to approximate a production setup — secure, scalable, and fast — but built with open standards and as little custom code as possible.

The high-level architecture was therefore simple: trades and instruments flowing from a Postgres instance; market prices piped in from a cloud WebSocket feed; a materialized view for the positions logic; and results streamed out to a grid in the browser.

Choosing the Streaming Database

One of the first big decisions was picking a streaming database to power the backend. I went with Materialize because it ticked all the boxes: broad SQL support, streaming over a standard Postgres connection, and strong consistency guarantees. But this space is evolving fast, and there were other solid contenders.

Materialize

Materialize positions itself as a 'live data layer' for apps and agents. It supports Postgres-compatible SQL, is built in Rust, and uses Timely and Differential Dataflow under the hood, enabling low latency and strong consistency across all views. You can query results on-demand or push updates out over Kafka or a Postgres connection, and it's easy to get started with their hosted offering and local development emulator.

RisingWave

RisingWave describes itself as a ‘real-time event streaming platform’ and appears similar to Materialize at first glance - SQL-first, Rust-based, and designed to make stream processing feel like working with Postgres. It’s fully open source, built around open storage formats like Apache Iceberg, and has a high-performance ‘Ultra‘ edition designed for use cases in financial markets and online betting. Unlike Materialize however, it doesn’t guarantee strict consistency, meaning views can be temporarily out of sync.

ksqlDB

ksqlDB is a streaming SQL engine for working with real-time data in Kafka. It supports SQL-like queries over Kafka topics, is source-available, and has built-in support for other Confluent products like Schema Registry. However, it uses its own SQL dialect rather than Postgres-compatible SQL, and Confluent now recommends Flink for new stream processing work.

Deephaven

Deephaven is a Python-based real-time engine originally built at a hedge fund, tailored for financial data workflows. It comes with its own UI server and scripting environment, so you can build full-stack UIs with just a few lines of Python. It’s powerful and polished, and would be a great choice if I were building this scope “for real.” But it’s a bit of an outlier — most streaming databases don’t bundle a UI server — so it didn’t feel like a good fit for this experiment.

Building the Data Layer

With the streaming database chosen, I spun up a Materialize emulator instance — a single-container version of Materialize with the same developer experience as a production setup. Then, I could plug in trades and instruments from Postgres and market prices from a live feed, and build the positions logic on top.

Trades and Instruments

For trades and instruments, I used Neon — a managed Postgres service that’s quick to set up and has a free tier. I used Claude to generate the tables and some fake data, and created a ‘publication’ so Materialize could subscribe to updates in real-time. I registered Neon as a source in Materialize, and the data was live.

Market Data

To keep things realistic, I wanted to use real market data delivered over WebSockets. Claude suggested a few great options — like Databento (great for latency-sensitive use cases) and Polygon (broad instrument coverage) — but I decided to go with Alpaca for its free tier and clean API.

That’s when I realized I’d missed something: Materialize doesn’t support WebSockets as a source. Oops. I could’ve switched streaming database (to e.g. Deephaven) or written a custom process to transform the data, but I wanted to avoid changing stack or adding glue code.

That’s when I found Estuary Flow: a real-time ETL tool with native support for both Alpaca and Materialize. Within a few minutes, I’d configured Estuary’s Alpaca connector for the IEX trades stream, mapped it to a Kafka topic, and registered it as a source in Materialize. Live prices were streaming in.

Positions

The final step was to pull trades, instruments, and market prices together into a live positions view. I had Claude generate two materialized views: one to surface the latest trade price per instrument, and another to join everything together, aggregate trades into positions, and calculate market value and P&L.

I ran SELECT * FROM live_pnl; and, after a short ‘hydration’ period, watched my positions update in real time as trades and prices streamed in.

So far so good! I had a real-time view of positions, aggregated from trades and live prices, with just a few lines of SQL.

Getting Data to the Browser

The next step was getting data from Materialize to a UI in real time, with minimal code. I began by looking into whether anyone had done this before, and what tools they’d used to make it work.

I found surprisingly little. There was a Materialize plugin for Grafana, which wasn’t a good fit given Grafana’s focus on monitoring. Some people were piping views to database tables to feed Streamlit or Metabase dashboards, which wasn’t truly real-time. But most commonly, people were building their own lightweight processes to stream data over WebSockets, like this blog post using Deno and Chart.js.

So I started looking more broadly. Were there other approaches that could work for my use case?

REST and GraphQL

First I explored exposing Materialize over REST or GraphQL, both common APIs for front-end data access. REST was a non-starter — it isn’t built for real-time — but GraphQL supports subscriptions and is well supported by most frontend frameworks.

That led me to Hasura, a data access layer for Postgres. It exposes your database as a GraphQL API with minimal setup, featuring built-in filtering, joining, and access control. Since Materialize is Postgres-compatible it seemed like a perfect fit, but Hasura polls periodically rather than streaming changes in real time, which wouldn’t give me the tick-by-tick updates I needed.

I also looked at Apollo, a more flexible way to build GraphQL APIs over any data source. It looked promising, but I’d still have needed to build an integration for Materialize. Since the main goal was to get streaming data into a UI with minimal effort, I didn’t want to add another platform and a bunch of glue code.

View Servers

Next I explored view servers, which are common in many financial markets applications. These components typically stream data from a data source to frontends over WebSockets, with built-in rate limiting and access control. Genesis and Deephaven, for example, both feature UI servers as part of their larger platforms (e.g. Genesis’ Data Server), but these aren’t available as standalone components.

FinOS Vuu was promising as an open source project designed for fast-moving data and many connected users. While it seemed straightforward to integrate and get running, I would’ve also needed to adopt its built-in grid, whereas I was more looking to compose a solution from standalone components.

Streaming API Gateways

Finally I looked at streaming API gateways, which serve Kafka topics over standard web protocols. The idea was to stream the positions view out through a Kafka sink, so a gateway could cache the latest rows and push them to any number of connected UIs without adding load on Materialize.

I started with Lightstreamer, a push server widely used for real-time apps in finance, gaming, and aerospace. It’s built for high-volume, low-latency data, with an open-source Kafka connector and throttling for slow clients. However, it uses its own protocol and client library, whereas I was looking to use open standards. I also looked at Gravitee, a full API management platform with its own console and database, but its Kafka support is only in the paid Enterprise edition.

Then I came across Zilla, a lightweight gateway that’s quick to set up, with everything defined in a single YAML file. It was a great fit, since it supports open standards like server-sent events (SSE), gRPC, and MQTT, and has authentication, row-level entitlements, and filtering available in its community edition. I configured Zilla to read positions from a compacted Kafka topic and stream them over SSE, ready for the UI to pick up.

Building the UI

Since the UI was simple — just a grid connected to an SSE stream — I went with plain HTML and JavaScript. I used Vite to build and serve it locally, so I could see changes instantly in the browser as I iterated.

For the grid, I needed something that could handle large, streaming datasets. I chose AG Grid as it had worked well for similar applications at Genesis, given its support for row virtualization and transaction updates.

To get data into the grid, I subscribed to Zilla’s SSE stream using the standard EventSource API. As events arrived, the UI determined whether each was an insert, update, or delete, and applied it to AG Grid as a transaction. You can find the code on GitHub: tycoworks/positions-app.

Conclusion

So, can a streaming database power a real-time financial markets application? I believe so. I built a real-time positions UI with Materialize at its core, with about 30 lines of SQL and 120 of JavaScript. And since it used proven, off-the-shelf parts, there was a clear path to production, even if I hadn’t optimized for latency, scale, or security.

While getting data into Materialize was straightforward, getting data out was fiddlier than expected. Zilla itself was easy to get up and running, designed for performance, and had entitlements, filtering, and scalability built in. However, going through Kafka meant defining every view up front in Materialize, whereas many applications need arbitrary queries and joins on the fly.

Is there a product here? Something based on GraphQL, like Hasura but for streaming databases? Is there demand for streaming data into UIs, or is the bigger opportunity in powering AI agents? That’s what I’ll look at next.