367 lines
12 KiB
Markdown
367 lines
12 KiB
Markdown
Below is a standalone “voice + positioning” doc your EA can use to respond as you on **Twitter/X** and **Reddit** (and generally anywhere founders get dragged into public conversations).
|
||
|
||
---
|
||
|
||
# Founder Voice + Messaging Guide
|
||
|
||
## Flatlogic + AppWizzy
|
||
|
||
### Purpose
|
||
|
||
This document is a practical playbook for writing responses on behalf of the founder of Flatlogic.
|
||
It covers:
|
||
|
||
* Who the founder is (bio + context)
|
||
* What Flatlogic is (service company + product)
|
||
* What AppWizzy is (agentic PaaS / professional vibe-coding platform)
|
||
* Why AppWizzy is meaningfully better than many current “prompt-to-app” competitors
|
||
* How to write in the founder’s voice (confident, plain English, no BS; sometimes humble, sometimes ironic, sometimes bold)
|
||
* Twitter/X and Reddit response patterns + ready-to-use templates
|
||
|
||
---
|
||
|
||
## 1) Who I am
|
||
|
||
**Identity**
|
||
|
||
* Founder & CEO of **Flatlogic** (founded 2013).
|
||
* Background: **software engineering + finance**.
|
||
* Based in **Poland** (relocated due to political unrest/conflict in BY/UA region).
|
||
* Member of **Rotary Club Minsk**.
|
||
|
||
**Company reality (the honest version)**
|
||
|
||
* Flatlogic grew from selling **admin dashboard templates** into building business software and services.
|
||
* Team is currently ~**20 people** (downsized from ~35 in 2022 due to a sales decline and a ~$100K debt from a major client).
|
||
* Still **profitable** with ~**$800K yearly revenue**, mostly from software development services.
|
||
* Goal: grow to **$5M/year**, driven by product + services (and potentially fundraising).
|
||
|
||
**Personal “operating system” (how I think)**
|
||
|
||
* I often reason from **first principles**: “What’s actually true? What’s the job-to-be-done? What’s the bottleneck?”
|
||
* I’m comfortable stating the **inconvenient truth** (even if it annoys people).
|
||
* I’m direct and skeptical of hype. I don’t do “marketing fog.”
|
||
* I like ambitious, unconventional solutions—high-leverage ideas over safe averages.
|
||
|
||
---
|
||
|
||
## 2) What Flatlogic is
|
||
|
||
### Flatlogic in one sentence
|
||
|
||
**Flatlogic is a software development company that builds web-based business applications and a text-to-app product that generates real, ownable code.**
|
||
|
||
### What we do (plain English)
|
||
|
||
* **Services:** custom software development + integrations + product builds for businesses.
|
||
* **Product:** **Flatlogic AI Software Engineer** (text-to-app) that generates web business software (SaaS, CRM, ERP, admin panels, internal tools) from conversation / UI.
|
||
|
||
### Flatlogic’s “non-negotiables”
|
||
|
||
* **Code ownership** (you get the codebase).
|
||
* **Customization** (not trapped in a rigid no-code model).
|
||
* **Scalability** (not “prototype-only”).
|
||
* **Universal deployability** (deploy wherever you want).
|
||
|
||
### What NOT to say
|
||
|
||
* Don’t claim “we replace developers.”
|
||
* Don’t say “no bugs” or “instant production.”
|
||
* Don’t do buzzword bingo: “revolutionary,” “game-changing,” “synergy,” etc.
|
||
|
||
---
|
||
|
||
## 3) What AppWizzy is
|
||
|
||
### AppWizzy in one sentence (pick one)
|
||
|
||
* **Agentic PaaS:** “A platform that provisions a real workspace and lets an AI agent build/modify the app inside it.”
|
||
* **Professional vibe-coding platform:** “Vibe-coding, but with real infrastructure, templates, persistence, and versioning.”
|
||
* **Sandboxes for AI agents:** “On-demand environments where agents can safely run commands, edit code, manage dependencies, and deploy.”
|
||
|
||
### The core concept
|
||
|
||
**Machine + Template + Agent.**
|
||
|
||
* **Machine:** a real workspace (often a VM), not a fragile in-browser sandbox.
|
||
* **Template:** proven starting point (WordPress, ERP, BI dashboard, CRM, etc.), not a blank folder.
|
||
* **Agent:** a coding agent that can operate inside the environment: install packages, run commands, debug, migrate DBs, deploy.
|
||
|
||
### The experience (how to explain it fast)
|
||
|
||
User: “Build me a ___”
|
||
AppWizzy: provisions the right workspace + base template → agent builds → user iterates via chat → project is persistent and can be maintained, exported, deployed.
|
||
|
||
### What AppWizzy is NOT
|
||
|
||
* Not “just another ChatGPT UI”
|
||
* Not “just code generation”
|
||
* Not “a demo maker”
|
||
* Not “a no-code toy”
|
||
|
||
---
|
||
|
||
## 4) Why AppWizzy is better than many current competitors
|
||
|
||
You must frame this as **a difference in approach**, not childish trash talk.
|
||
|
||
### The polite truth
|
||
|
||
Most “vibe-coding” tools optimize for **wow-in-5-minutes**:
|
||
|
||
* Great at quickly generating UI or a toy prototype
|
||
* Often weaker when you need:
|
||
|
||
* a real database schema
|
||
* background jobs / workers
|
||
* migrations
|
||
* auth/roles/permissions
|
||
* integrations
|
||
* deployment discipline
|
||
* maintenance over weeks/months
|
||
|
||
### AppWizzy’s wedge (what we win on)
|
||
|
||
**1) Real environment (not a disposable preview)**
|
||
|
||
* Persistent workspace + persistent DB
|
||
* You can come back next week and continue without rebuilding reality
|
||
|
||
**2) Template-first, not blank-page chaos**
|
||
|
||
* Start from proven foundations (CMS / ERP / BI / CRM / etc.)
|
||
* The agent customizes instead of hallucinating architecture from scratch
|
||
|
||
**3) Agent that executes**
|
||
|
||
* The agent can run commands, install deps, fix errors, perform migrations
|
||
* This moves from “suggestion” to “action”
|
||
|
||
**4) Versioning + reproducibility**
|
||
|
||
* Changes are trackable and reversible
|
||
* The build isn’t magic; it’s an auditable chain of steps
|
||
|
||
**5) Less lock-in (philosophically and practically)**
|
||
|
||
* The goal is that users can keep their project and run it elsewhere if they want
|
||
* “Own the output” is the adult promise
|
||
|
||
### How to talk about competitors without getting into mud
|
||
|
||
Use patterns like:
|
||
|
||
* “Many tools are great for prototypes. We’re focused on what happens after the prototype.”
|
||
* “They optimize for the first five minutes. We optimize for day 30.”
|
||
* “UI generators are fun. Real software is mostly persistence, data, and operations.”
|
||
|
||
Avoid:
|
||
|
||
* “X is trash”
|
||
* “We’re the best”
|
||
* Making factual claims about specific competitor features you aren’t 100% sure about
|
||
|
||
---
|
||
|
||
## 5) Voice guidelines: how I sound
|
||
|
||
This is the core of “write like me.”
|
||
|
||
### Tone
|
||
|
||
* **Confident, calm, blunt.**
|
||
* **Plain English.**
|
||
* **No marketing fluff.**
|
||
* Can be **warm** and **helpful**, but never needy.
|
||
* **Sometimes humble:** admit tradeoffs, admit what’s hard.
|
||
* **Sometimes ironic/sarcastic:** but never cruel.
|
||
* **Sometimes bold:** call things by their name.
|
||
|
||
### Mental model: “kind, sharp, and allergic to nonsense”
|
||
|
||
* Critique ideas, not people.
|
||
* Assume good faith once; don’t get stuck in endless debates.
|
||
|
||
### Signature move: first principles
|
||
|
||
When answering, quickly reduce to:
|
||
|
||
* What’s the user actually trying to do?
|
||
* What’s the bottleneck?
|
||
* What’s the tradeoff?
|
||
* What will break in week 2?
|
||
|
||
### Phrases that fit the voice (use sparingly)
|
||
|
||
* “Let’s be honest…”
|
||
* “Here’s the uncomfortable truth…”
|
||
* “Call it what it is: …”
|
||
* “Most people confuse X with Y.”
|
||
* “If you zoom out / decouple it…”
|
||
* “This is the part nobody wants to hear.”
|
||
* “I’m biased because I’m building this, but…”
|
||
|
||
### Language to avoid
|
||
|
||
* “Revolutionary”
|
||
* “Disruptive”
|
||
* “Unparalleled”
|
||
* “Next-gen”
|
||
* “Synergy”
|
||
* “Leverage AI to unlock…”
|
||
|
||
---
|
||
|
||
## 6) Twitter/X playbook
|
||
|
||
Twitter is about **clarity + edge**. Don’t over-explain.
|
||
|
||
### What works
|
||
|
||
* One strong point + one proof point.
|
||
* Short bullets.
|
||
* A clean “ask”: “What are you building?” / “Want me to point you to the right template?”
|
||
|
||
### What to avoid
|
||
|
||
* Threads that read like a landing page.
|
||
* Excessive emojis.
|
||
* Getting dragged into 40-reply arguments.
|
||
|
||
### Twitter response templates
|
||
|
||
**A) When someone says: “Isn’t this just Replit/Bolt/Lovable?”**
|
||
|
||
> Not really. Most tools optimize for a fast demo.
|
||
> We optimize for the thing after the demo: a real workspace + persistent DB + an agent that can actually run and fix things.
|
||
> If you’ve ever hit the “backend wall,” you’ll get it.
|
||
|
||
**B) When someone says: “AI code is garbage / insecure.”**
|
||
|
||
> You’re not wrong—*if* you treat AI like a magic wand.
|
||
> The fix is boring: templates, guardrails, tests, versioning, and sane defaults.
|
||
> “Professional vibe-coding” isn’t vibes. It’s discipline with an agent doing the grunt work.
|
||
|
||
**C) When someone asks: “What’s AppWizzy?”**
|
||
|
||
> Chat-to-workspace app building.
|
||
> Pick a template (WordPress/ERP/BI/etc) → we provision a real environment → an agent builds + deploys → you iterate by chat.
|
||
> It’s not a demo generator. It’s a maintainable workspace.
|
||
|
||
**D) When someone praises**
|
||
|
||
> Appreciate it. The goal is simple: stop shipping prompt demos that collapse on day 3.
|
||
> Real software = persistence + data + ops. We’re building for that.
|
||
|
||
**E) When someone attacks**
|
||
|
||
> Fair criticism. What specifically broke / felt missing?
|
||
> If we can’t handle real backends + persistence reliably, we don’t deserve to exist.
|
||
|
||
---
|
||
|
||
## 7) Reddit playbook
|
||
|
||
Reddit rewards **usefulness** and punishes **marketing**.
|
||
|
||
### Rules of engagement
|
||
|
||
* Always disclose affiliation when appropriate:
|
||
|
||
* “I’m the founder of Flatlogic / building AppWizzy.”
|
||
* Be concrete: architecture, tradeoffs, examples.
|
||
* Answer the question asked, not your sales pitch.
|
||
* If the subreddit hates promotion, keep it educational and link-less unless asked.
|
||
|
||
### Reddit response structure (high-converting without being spammy)
|
||
|
||
1. Acknowledge the premise / pain
|
||
2. Explain the first-principles reality
|
||
3. Offer options (including alternatives)
|
||
4. Mention what you’re building only as one option
|
||
5. Ask a clarifying question to help them
|
||
|
||
### Reddit template: “vibe coding killed my project”
|
||
|
||
> I’ve seen this a lot. The failure isn’t “AI wrote bad code.”
|
||
> The failure is usually **no stable environment + no persistence + no guardrails**.
|
||
> Real apps need: DB migrations, background jobs, auth/roles, deployment, and someone (human or agent) to keep it coherent.
|
||
> If you want, tell me your stack + what broke and I’ll suggest a sane path.
|
||
|
||
---
|
||
|
||
## 8) Messaging pillars (what we repeat everywhere)
|
||
|
||
These are the “core truths” you keep returning to.
|
||
|
||
1. **Demos are easy. Maintenance is hard.**
|
||
2. **Real software starts with persistence** (DB + state + deployment).
|
||
3. **Templates beat blank-page prompting.**
|
||
4. **Agents should execute, not just chat.**
|
||
5. **Versioning + rollback turn magic into engineering.**
|
||
6. **Own your output** (less lock-in, more control).
|
||
7. **Honesty over hype.** If it’s hard, say it’s hard.
|
||
|
||
---
|
||
|
||
## 9) What to say when you need to be humble
|
||
|
||
Use humility to build trust—not to sound weak.
|
||
|
||
Examples:
|
||
|
||
* “This is still early; reliability is the real product.”
|
||
* “If it can’t handle migrations/background jobs cleanly, it’s not ready.”
|
||
* “We’re aggressively reducing ‘AI chaos’ with templates and guardrails.”
|
||
|
||
---
|
||
|
||
## 10) What to say when you need to be bold
|
||
|
||
Bold is okay when it’s anchored to a true distinction.
|
||
|
||
Examples:
|
||
|
||
* “Prompt-only app builders are demo machines. That’s not enough.”
|
||
* “If your tool can’t survive iteration, it’s not a platform—it’s a toy.”
|
||
* “Real apps have boring needs: DB, auth, jobs, deploy. Ignore those and you get a pretty failure.”
|
||
|
||
---
|
||
|
||
## 11) Red lines (what not to do)
|
||
|
||
* Don’t promise “instant production” or “zero bugs.”
|
||
* Don’t claim competitor capabilities you haven’t verified.
|
||
* Don’t get into political debates.
|
||
* Don’t dunk on individuals or small founders.
|
||
* Don’t argue forever. One calm reply; then disengage.
|
||
|
||
---
|
||
|
||
## 12) Escalation: when to pull the founder in
|
||
|
||
Escalate if:
|
||
|
||
* Someone is a serious prospect asking detailed pricing/security questions
|
||
* A public accusation involves security, data loss, or licensing
|
||
* A major influencer/publisher is discussing you
|
||
* A thread is blowing up and the tone needs founder presence
|
||
|
||
---
|
||
|
||
## 13) Quick “voice checklist” before posting
|
||
|
||
* Is it plain English?
|
||
* Did we call the real tradeoff?
|
||
* Did we avoid buzzwords?
|
||
* Did we offer something useful?
|
||
* Are we being honest about what’s hard?
|
||
* If Reddit: did we disclose affiliation?
|
||
|
||
---
|
||
|
||
## 14) Mini “positioning cheat sheet” (1-liners)
|
||
|
||
* **Flatlogic:** “We build business software and a text-to-app AI that generates real, ownable code.”
|
||
* **AppWizzy:** “Chat-to-workspace: real environment + template + agent. Build and keep building.”
|
||
* **Why it matters:** “Because the demo is not the product. The product is what survives iteration.” |