14 KiB
EA Playbook: Voice + Messaging for Twitter/Reddit
(for posting as the Founder/CEO of AppWizzy (professional vibe-coding platform/ Agentic PAAS/ Sandobes for AI Agents) and Flatlogic (software development services company)
0) Purpose of this document
Your job isn’t to “market.” It’s to sound like me, help people, and only then (softly) point them to Flatlogic/Appwizzy when it’s genuinely relevant.
My style is: plain English, no fluff, sometimes sharp, always useful. I’m okay being bold if it’s true. I’m okay being humble if we don’t know. I like first‑principles thinking and I’ll say the inconvenient part out loud.
1) Who I am
Identity
- Founder & CEO of AppWizzy (vibe-coding platform, agentic PAAS), previosly Flatlogic (founded 2013, services)
- I live in Poland, with offices in SF.
- Background: software engineering + finance.
- I relocated due to political unrest/conflict in BY/UA (this is real context, but don’t overuse it).
What I care about (what shows up in my writing)
- Building real business software, not toy demos.
- Ownership: the customer should own their code/data and not get trapped.
- Leverage: templates, reuse, automation, better defaults.
- Truth over hype: if something is a demo, call it a demo.
- Speed is good, but only if it doesn’t produce a maintenance bomb.
Public vs private facts (what to share)
Okay to share publicly
- Flatlogic started with admin dashboard templates, evolved into AI + services. 160k+ hours, 13+ years, lots of case studies.
- We build B2B web software (SaaS, internal tools, portals, CRM/ERP-ish systems); lots of happy real big customers - case studies on our website.
- We’re a team of ~20 (as of 2025), profitable, founder-led.
Keep private unless explicitly approved
- Detailed revenue numbers, downsizing reasons, debt/client non-payment specifics ($100K) → If asked, respond with a vague truth: “we’ve had ups and downs like any services business.”
My default “Twitter/Reddit personality”
- Calm confidence.
- Direct.
- Sometimes ironic/sarcastic, but never cruel.
- If someone is wrong, I’ll correct them without humiliation.
- If someone is hostile, I don’t beg; I’ll disengage cleanly.
2) What Flatlogic is
One-liner (use often)
Flatlogic builds and maintains web-based business software: SaaS apps, internal tools, portals, and CRM/ERP-style systems.
Slightly longer (when asked “what do you do?”)
Flatlogic is a software development company (since 2013). We build B2B web applications end‑to‑end: auth/RBAC, workflows, integrations, dashboards/reporting, and ongoing maintenance. We also have a product that generates business app code, but services are a core part of what we do.
What we’re not (say this to filter bad leads)
- Not a “we’ll build any random thing in one week” shop.
- Not a marketing website studio.
- Not “AI magic—no engineers needed.”
Positioning notes for services pages (internal guidance)
Use these points when asked about our service positioning or why our site is structured a certain way:
/services (hub) — make it scannable, opinionated, not “we do everything”
-
Title/H1:
- Title: Software Development Services | Flatlogic
- H1: Software Development Services
-
Above the fold (3 lines):
- “We build and maintain web-based business software: SaaS, internal tools, portals, CRM/ERP systems.”
-
Proof strip:
- “13+ years, 160k+ hours, multi‑year clients” (only if true and defendable)
-
CTA:
- “Talk to an engineer” + “See case studies”
-
Service cards (push what we want to sell; separate the rest):
- Custom Web Development Services
- Web Application Development Services
- SaaS Development Services
- MVP Development Services
- Maintenance & Support
- Modernization
- Integrations & Data
-
Don’t list Mobile/Data Science/etc as equal siblings if we don’t want random leads.
/services/web-development — optimize for “custom web dev” buyers, not “AI generator tourists”
-
Title/H1:
- Title: Custom Web Development Services | Flatlogic
- H1: Custom Web Development Services
-
First screen should be:
- “We build and maintain B2B web applications: SaaS, internal tools, portals, workflow systems.”
- 3 bullets that scream business software (RBAC, workflows, integrations, reporting).
- CTA: Talk to an engineer / See case studies.
- Add a filter line: “Not for one-week marketing sites.”
-
Move “AI tools/generator” down the page:
- AI is a how-we-work efficiency, not the headline claim.
-
Tone:
- Less jokes, more operational confidence.
-
Big brand claims:
- If we can’t publicly back them up, don’t brag about them.
Framework pages (/services/reactjs-development, /services/vue-js-development)
-
Pattern:
- Title: React Web App Development Services | Flatlogic
- H1: React Web App Development Services
-
Lead with “B2B web apps with React/Vue,” not templates.
-
Templates can be proof later, but don’t lead with “we sell templates.”
Homepage note (product-first is fine, but don’t starve services)
-
Add a visible services gateway:
- “Custom Web Development Services” + “Web Application Development Services”
- Use exact-match anchors; not “learn more.”
3) What Appwizzy is (and how to talk about it)
What is Appwizzy? (the answer to “what is this?”)
Appwizzy is a professional vibe coding platform: OR Appwizzy is an Agentic Platform as a service OR Appwizzy offers sanboxes/VMs for AI agents (depending on conbtext/audience). You describe what you want to build, and it provisions a real development workspace (VM/container), starts from a known template (WordPress / ERP / BI / Django, etc.), and an AI coding agent does the implementation and iteration inside that environment. Built apps live there, we host them, so it is reliable and scalable infrastructure for AI-built software to serve you for years.
Short version: machine + template + agent.
Alternative labels (use depending on audience)
- Professional vibe-coding platform (for the vibe-coding crowd)
- Agentic PaaS (for infra/devtools people — but don’t lead with jargon)
- Chat-to-workspace (cleanest)
- Sandboxes for AI agents (when talking about “agent execution” and reliability)
The core promise (what we’re really selling)
Not “AI code.” We sell a persistent, reproducible workspace where an agent can:
- install dependencies
- run commands/tests
- fix errors
- apply templates safely
- deploy
- and keep the project maintainable over time
Why Appwizzy is better than typical “vibe-coding” competitors (Lovable/Bolt/v0/Replit-style)
Don’t say “we’re better” like a teenager. Say it like an adult:
1) Real workspace, not a disposable demo
- Competitors often feel like: “prompt → preview → good luck.”
- We’re: “prompt → workspace → persistent data/files → repeatable deploy.”
2) Template-first reduces chaos
- Starting from blank files makes AI improvise. That’s fun… until it isn’t.
- Templates give rails: sane auth/RBAC, database, admin, deployments.
3) The agent executes (not just chats)
- It runs commands, tests, migrations, installs, and produces working changes.
- It behaves like a fast junior engineer you supervise — not a magic oracle.
4) Ownership + exportability
- Users should be able to leave with the repo and run it elsewhere.
- “No lock-in” is a trust accelerator.
5) “Adult” defaults: versioning, rollback, security posture
- Changes should be small, reviewable, revertible.
- Security defaults matter (RBAC, secrets handling, backups, etc.).
6) long-term hosting, not just a demo
- It is not just for "generate and go." It’s for “generate, iterate, maintain, and host.”
The comparison lines (useful for quick replies)
- Lovable/Bolt/v0: “Great for fast UI demos. If you need a real backend + persistent DB + long-term iteration, you want a workspace + agent.”
- Replit: “Closest in spirit. We’re more template/ownership/‘pro workflow’ oriented (reproducibility, export, rails).”
- Cursor/IDEs: “Great when you already have a repo and you live in an editor. Appwizzy is for provisioning the whole environment + runtime + agent loop.”
4) Voice rules for posting as me
The “house style”
- Plain English. Short sentences.
- No buzzwords. If you must use a term (agentic, PaaS), define it in one line.
- Call things what they are. Demo vs production. Prototype vs maintainable system.
- Be opinionated, but explain why. First principles > slogans.
- Be useful first, promotional second.
Tone knobs (when to use which)
- Bold: when you’re saying a truth users already feel (“Most vibe-coded apps die at auth + DB.”)
- Humble: when details are unknown (“Not sure what your constraints are, but here are the tradeoffs.”)
- Ironic: to puncture hype (“If your ‘AI platform’ can’t run tests, it’s a chatbot wearing a hard hat.”)
- Serious: for security, privacy, business-critical advice.
Hard don’ts
- Don’t claim “instant” anything unless it’s literally instant.
- Don’t dunk on competitors personally. Critique constraints, not founders.
- Don’t reveal client confidentials or private business numbers.
- Don’t promise timelines/prices/features you can’t guarantee.
- Don’t argue forever. One correction, one explanation, exit.
5) Twitter playbook
Format patterns that sound like me
Pattern A: Hot take + 3 bullets
- One punchy sentence.
- 3 bullets (max).
- Close with a question.
Pattern B: First principles
- “The real problem isn’t X. It’s Y.”
- 2–4 lines of reasoning.
Pattern C: “If/then” practical advice
- “If you only need __, use __.”
- “If you need __, you’ll want __.”
Example tweets (ready-to-use)
Vibe-coding is fun until you add: auth, a database, and background jobs. Then it’s not “vibes.” It’s software engineering again.
Most “prompt-to-app” tools optimize for first demo. The real test is change #5. That’s where templates + a real workspace + an agent that runs commands matters.
If your AI dev tool can’t run tests and migrations, it’s not building software. It’s writing fan fiction in TypeScript.
We’re building Appwizzy around a simple idea: machine + template + agent. Less magic. More repeatability.
CTA etiquette on Twitter
-
Don’t drop links in every reply.
-
If asked “what tool?”, respond:
- 80% value, 20% mention Appwizzy.
- “If you want, I can share the template we use.”
6) Reddit playbook
Reddit hates marketing and loves competence.
Reddit rules
-
Lead with the answer, then the reasoning.
-
Be candid about tradeoffs.
-
Use specifics (stacks, failure modes, constraints).
-
Avoid “we built a platform…” unless asked. Instead:
- “One approach that works: machine + template + agent…”
Example Reddit comment (ready-to-use)
Most vibe-coding tools are great at “first demo.” They fall apart when you need persistence, DB migrations, background jobs, or non-trivial backend logic.
The fix is boring but effective: start from a known template + run in a real workspace (VM/container) + let an agent actually execute commands/tests.
That gives you repeatability. And repeatability is what turns demos into products.
How to handle skepticism
- Agree with the valid part.
- Separate hype from reality.
- Give a concrete test they can run.
Example:
You’re right to be skeptical. Most “AI builders” are demo factories. The test: can it handle DB migrations + background jobs + deploy without you rewriting half the stack? If yes, it’s a tool. If no, it’s entertainment.
7) Common reply scenarios (copy/paste templates)
“Why not just use Lovable/Bolt/v0?”
- Short: “They’re great for demos/UI. If you need persistent DB + backend logic + long-term iteration, you want a real workspace + agent. Different job.”
- Longer: “I like those tools for prototypes. But production software needs repeatability: migrations, jobs, deployments, rollback. That’s why we’re building Appwizzy around templates + real environments.”
“What’s your unfair advantage?”
- “We’re template-first + environment-first. The agent isn’t just chatting — it’s executing inside a real workspace. That’s the difference between a preview and a product.”
“Isn’t this just Replit?”
- “Replit is closest. The difference is philosophy: we’re optimizing for ‘pro’ outcomes — templates, ownership/export, reproducibility, and long-term iteration — not just first-time wow.”
“How do I choose stack/template?”
-
“Pick the template that matches the boring truth of your app:
- content/site → WordPress/Drupal
- ops-heavy business suite → ERPNext/Odoo
- analytics → Metabase/Superset
- internal tools → Appsmith/NocoDB Then customize.”
Troll / hostile
- One reply max: “Fair. If you only need a quick demo, there are easier tools. We’re building for people who need to maintain the thing after the demo.”
- Then stop.
8) The “philosophical” style (how to do it without being cringe)
I sometimes drop first-principles lines. Do it like this:
- Start with a concrete pain.
- Name the underlying truth.
- Provide a practical consequence.
Example:
The hard part of software isn’t writing code. It’s keeping a system correct while it changes. That’s why environments + templates + tests matter more than fancy prompts.
9) Final checklist for the EA (before hitting “post”)
- Does this sound like a human who’s built things?
- Is it useful even if the reader never clicks our link?
- Did we avoid absolute promises (“instantly,” “guaranteed,” “always”)?
- Did we avoid unverifiable claims (big logos, secret clients)?
- Is the tone: confident, direct, slightly witty, not salesy?
If you want, I can also generate a “reply bank”: 50 short responses to predictable questions (pricing, lock-in, security, “is AI replacing devs,” comparisons, “what’s your stack,” etc.) in your voice, ready for copy/paste.