Build in Public Tools

Start with the tools already in the work

Do not assemble a creator stack before you have something to document. A text file, working URL, screenshot tool, and one place to publish are enough for the first month.

Choose tools by the job they perform and the cost of maintaining them.

Durable project home

• GitHub for repositories, READMEs, issues, release notes, and discussions around technical work.
• A personal website for long-term ownership, search, and connecting several projects.
• Substack or Buttondown when email and an article archive are the primary format.

Raw capture

• A local Markdown file for private work notes.
• Git commits and pull requests for changes that belong beside code.
• Obsidian when local linked notes are useful.
• Notion when a shared workspace matters more than plain files.

The capture tool should be faster than deciding not to write.

Visual evidence

• The operating system screenshot tool for simple proof.
• Excalidraw for rough diagrams that should look unfinished.
• Figma for interface drafts and collaborative design.
• OBS Studio for screen recording and livestreaming when video genuinely clarifies the work.

Review every capture for credentials, customer information, private tabs, notifications, and location details.

Feedback

• GitHub Issues for specific bugs and actionable project work.
• GitHub Discussions for broader questions and conversations around a repository.
• Tally for a lightweight structured form.
• Direct interviews or observed use when behavior matters more than a survey answer.

Analytics

• Server logs or a small first-party counter when you need only basic reach.
• Plausible for focused web analytics.
• PostHog when product events, funnels, or session-level product learning are necessary.

Install analytics only after writing the decision it will inform. More data does not automatically create more understanding.

Payments

Do not build a custom checkout before someone is ready to pay. Begin with a hosted payment link, a platform checkout, or a local bank transfer that produces a clear receipt and requires little maintenance.

• Stripe Payment Links for a hosted checkout with a direct payment-processor relationship.
• Polar for developer-focused digital products, subscriptions, and benefits under a merchant-of-record model.
• Lemon Squeezy or Paddle when a merchant of record fits the product and operating model.
• VietQR for a straightforward local bank-payment path in Vietnam.

The important choice is not the logo on the button. It is who handles tax, refunds, disputes, subscriptions, invoices, and payouts. The Payments guide explains the main models and when each one becomes useful.

A minimum toolkit

For most beginners:

Private notes: one Markdown file
Public home: one README or website
Evidence: screenshots
Feedback: one direct channel
Review: one weekly note

Add a tool only when the current system creates a repeated limitation.