How I Built PRESENT.fast, a Markdown to Slides Tool for Busy Professionals

The first version of PRESENT.fast is intentionally focused.

Users can:

• Write or paste markdown
• Use -- to separate slides
• Choose what text goes into each slide
• Transform bullet lists into cards
• Use different layout options for slides with images
• See a live presentation preview
• Present directly inside the app
• Create multiple slide decks
• Save, edit, archive, and delete presentations
• Share a public presentation link with view only access
• Export presentations as images in different size formats

The edit screen is the part of the UX I am happiest with. It shows the markdown source on the left, the slide structure in the centre, and the presentation preview on the right.

That layout captures the core idea of the product. You stay close to the writing, but you can immediately see the presentation taking shape.

For the first version, I intentionally left out several features:

• Custom themes
• Extensive formatting controls
• AI-powered slide generation
• Advanced design options
• Complex template systems

Those features could all be useful, but they would have made the first version take much longer. I wanted to launch an MVP quickly, validate the idea, and avoid turning a focused tool into a heavy presentation platform before anyone had used it.

That is always harder than it sounds.

When you are building with AI tools, implementation feels cheaper, so it becomes very easy to keep adding “just one more thing”. But every feature still needs design decisions, edge case handling, testing, and maintenance.

For this version, the constraint was clear: markdown in, usable presentation out.

I built PRESENT.fast with a stack that let me move quickly while still treating the product as something real users could use.

The main stack includes:

• Next.js
• React
• TypeScript
• Tailwind CSS
• shadcn/ui
• Lucide React icons
• Convex
• Clerk
• Vercel
• Resend
• react-markdown

I used Next.js, React, TypeScript, Tailwind, and shadcn/ui because they are familiar tools for me, and familiarity matters when trying to launch quickly.

For the backend, I used Convex. Part of the motivation was practical curiosity. I had heard good things about it and wanted to try it in a real product rather than just a toy example.

PRESENT.fast stores presentation data in Convex, including the markdown content, user-related data, sharing identifiers, and other app state needed to create, edit, archive, delete, and share presentations.

Because the product is built around markdown, react-markdown became an important part of the rendering flow. The app takes the markdown source and turns it into presentation slides based on structure and conventions, such as using --- as the slide separator.

The markdown parser and renderer became one of the more interesting technical challenges.

At first glance, markdown feels simple. Headings, paragraphs, bullets, images, code blocks. But once you start turning markdown into slide layouts, the complexity increases. A bullet list might be rendered as normal bullets in one case, cards in another case, or part of a more visual layout depending on the slide type.

Some markdown combinations still do not parse as cleanly as I would like, and this is one of the areas I want to improve. The difficult part is finding a balance between supporting enough markdown to be useful and avoiding an overly complex formatting engine.

A presentation tool has a hidden constraint that normal markdown pages do not have: each slide has limited space. That means parsing content is only part of the problem. The rendered result also needs to feel readable, balanced, and presentable.

One part of the project I seriously underestimated was authentication.

On paper, it sounded straightforward:

• Add Clerk
• Enable GitHub login
• Enable Google login
• Connect it with Convex
• Deploy everything to Vercel

In practice, it turned into a few hours of carefully wiring services together across production, development, and preview environments.

The difficult part was not any single step. The difficult part was making sure every service had the right configuration, the right API keys, the right environment variables, and the right assumptions about the environment currently running the app. Plus, all the testing.

Clerk, Convex, and Vercel each have their own way of thinking about environments. That is powerful, but it also means you need to be careful. A small mistake, such as using the wrong key in the wrong place, can break login flows in ways that are not always obvious at first.

Then there was the extra product polish around login.

I had to make sure the PRESENT.fast name and logo appeared properly in the authentication flow and emails sent to users. This was not too difficult with Clerk, but it was another reminder that real products are made of many small details.

I also had to create Privacy Policy and Terms of Service pages. Google login requires that kind of setup, and those pages are important because they explain how user data is handled. Then I wired up Resend for the contact form so users could reach out from the site in case they find bugs or want to submit feedback.

None of these tasks felt like the main product feature, but they mattered.

A login experience that feels disconnected from the product makes the whole app feel less trustworthy. A missing privacy policy can block OAuth setup. A contact form needs proper email handling. Branding needs to appear consistently across different services.

This is the side of SaaS development that is easy to forget when imagining the product from the outside.

AI played a major role in building PRESENT.fast.

I used a mix of:

• v0
• Claude Code
• Cursor
• ChatGPT

The initial mockup came from v0, which was a huge time saver. It helped me move from idea to working visual direction much faster than I would have done manually.

From there, I used Claude Code and Cursor during the development process, following a loose version of a research, plan, implement, review, and test workflow.

That workflow was important because the project had enough moving parts to become messy:

• Markdown parsing
• Slide rendering
• Presentation mode
• Authentication
• Convex data storage
• Public sharing
• Image export
• Responsive UI
• Landing page copy
• Environment configuration

AI helped across product thinking, UI implementation, architecture decisions, debugging, and content. It was especially useful for scaffolding the initial structure and connecting services together.

But the project also reminded me where AI still struggles. The UI required a lot of manual direction. AI can generate components quickly, but it does not always produce a consistent experience across the whole app. A component might look good in isolation and still break when placed inside a real layout with responsive behaviour, overlapping elements, edge cases, empty states, and mobile screens.

The mobile version took more manual work than expected (it still needs some polishing). Fixing overlapping elements, refining spacing, and making interactions feel right still required careful human review.

That is one of the main lessons I keep seeing with AI-assisted development:

AI is excellent for acceleration, but the developer still needs to own the product direction, the quality bar, and the final experience.

The main design goal for PRESENT.fast was to make the product feel simple and direct. I wanted users to see the markdown source and the presentation preview in the same workspace. That way, editing does not feel disconnected from the output.

The app is meant to feel minimal, polished, and presentation-focused, so the editing experience is built around three main areas:

1. The markdown source
2. The generated slide structure
3. The presentation preview

This layout helps keep the user close to the content by keeping the writing, slide structure, and final output visible in the same workspace. Instead of spending time arranging elements around a blank canvas, the user can focus on shaping the message in markdown and let the tool translate that structure into slides.

For users who already think in markdown, writing is often faster than designing slides manually. Instead of deciding where every text box should go, you decide what the presentation should say and how the content should be separated.

There are still rough edges, though 😅. Some interactions in presentation mode need more polish. Some markdown formatting combinations need better support. Image zooming in presentation mode has already come up as feedback from users.

But the foundation feels right. The product is at its best when the user can paste structured notes, make a few edits, and quickly reach something they would actually feel comfortable presenting.

The landing page took longer than I expected, and this has become a recurring theme in my projects. Building the app is difficult, but explaining the product clearly is a different kind of challenge.

For PRESENT.fast, I reused a custom ChatGPT project I had created specifically for landing pages. That project contains selected resources about positioning, messaging, landing page structure, and conversion-focused writing.

Instead of asking ChatGPT to simply “write a landing page”, I asked it to interview me about the product.

The goal was to clarify:

• Who the product is for
• What problem it solves
• What workflow it replaces
• Why markdown matters
• Why speed matters
• What makes the product useful
• What the user should understand within a few seconds

That interview process helped me move beyond a basic feature list.

A feature list would have said something like:

• Markdown editor
• Live preview
• Presentation mode
• Public sharing
• Image export

Those features matter, but they do not fully explain the pain. The real message is closer to this:

You already have the content. The slow part is turning it into slides.

That framing helped shape the landing page. The page needed to show that PRESENT.fast is not just a markdown renderer with nice styling. It is a faster workflow for going from structured notes to something ready to present.

This is where AI was useful as a thinking partner rather than just a copy generator. It helped me pressure test the message, compare different angles, and refine the way the product explains itself.

Now that I have this landing page workflow, I can reuse it for future products and keep improving it.

I launched PRESENT.fast at the beginning of April. So far, a couple of coworkers have used it, and a couple of LinkedIn contacts have created accounts.

The most useful feedback has been practical. One person mentioned that presentation mode should allow zooming into images. That makes a lot of sense, especially for technical presentations where screenshots, diagrams, and architecture visuals often need a closer look.

One thing that surprised me, although maybe it should not have, is how difficult it is to get people to try a new product.

Building the thing is hard, but getting attention is harder.

This is something I keep learning with small SaaS products. The technical part can be difficult, but it is usually solvable with enough time, persistence, and debugging. Marketing is different. Distribution is different. Helping people understand why they should care is a much more open-ended problem.

At the moment, PRESENT.fast is completely free to use. Longer term, I can imagine a few possible monetisation paths:

• Custom themes
• More advanced exports
• AI-powered slide generation
• AI-assisted restructuring
• Team or workspace features
• Premium presentation styles

But for now, the priority is learning from usage and improving the core workflow.

If I started again, I would define the must-have features for the MVP more clearly before building.

I had a general idea of what the product needed, but there were moments during development where I second-guessed the scope. Should I add themes now? Should I add AI generation now? Should image layouts be more flexible? Should export options be more advanced?

Those questions are natural, but they slow the build process when the MVP boundary is not explicit enough.

For a small product like this, the MVP should be almost brutally clear:

• Users can paste markdown
• Slides are generated from that markdown
• The result looks good enough
• Users can present it
• Users can save and share it

Everything else can wait.

I would also try to use tools I already know wherever possible. Convex was interesting to learn, and I am glad I tried it, but every new service adds a learning curve. When the goal is speed, unfamiliar infrastructure can quietly consume more time than expected.

That does not mean developers should never try new tools. Side projects are a great place to learn. But if the main goal is launching quickly, familiar tools reduce friction.

I would also double my time estimate. A product that looks like it should take a weekend often takes several evenings once auth, deployment, mobile polish, legal pages, emails, edge cases, and feedback loops enter the picture.

From the outside, PRESENT.fast may look like a small markdown to slides tool. From my perspective, it was a complete product-building exercise.

It included:

• Identifying a real workflow problem
• Turning a work hack into a product idea
• Building a focused MVP
• Creating a markdown-based editing experience
• Rendering slide layouts from structured content
• Implementing authentication
• Connecting Clerk, Convex, Vercel, and Resend
• Supporting public sharing
• Adding export functionality
• Creating a landing page
• Using AI tools across the development process
• Launching publicly
• Getting early feedback from real users

The project also reinforced something I keep noticing:

Small products are rarely small in practice.

Even a focused app needs authentication, data modelling, permissions, UI polish, deployment, environment variables, product messaging, responsive design, and support workflows. The difference is that a small product gives you a contained way to practise all of those skills.

That is why I enjoy building these projects! They force you to connect product thinking with technical implementation.

You cannot hide inside code forever, because the product still needs to make sense to users. You also cannot stay only at the idea level, because the details eventually need to work.

PRESENT.fast gave me another chance to practise that full loop.

There are several features I would like to explore next.

Custom themes are one of the obvious ones. At the moment, the app only has one theme. That keeps the product simple, but different users and use cases would benefit from different visual styles.

AI-powered features are another interesting direction.

For example, AI could help users:

• Turn messy notes into cleaner markdown
• Suggest slide breaks
• Rewrite dense sections
• Convert long bullets into clearer cards
• Generate speaker notes
• Create title slide options
• Improve technical explanations
• Adapt the tone for different audiences

The important thing would be keeping the workflow controlled.

I do not want AI to take over the whole process in a way that makes the user fight the output. The current value of PRESENT.fast comes from control and speed. The user can decide what goes where, edit the markdown directly, and see the result immediately.

Any AI feature should support that workflow rather than obscure it.

PRESENT.fast started with a simple work problem: I had structured notes, I needed a presentation, and I did not want to spend the evening manually building slides.

A quick v0 prototype solved the immediate problem, but the reaction from coworkers showed there might be a broader use case. That small moment turned into a couple of weeks of building, polishing, wiring services together, launching, and learning.

The product is still early, but it is live, usable, and already doing the job I built it for. It helps turn markdown notes into presentations, fast, without making the user fight a blank slide canvas.

For developers, founders, product managers, and professionals who already write structured notes, that can remove a surprising amount of friction.

And sometimes that is enough reason to build the thing.