394 lines
14 KiB
Markdown
394 lines
14 KiB
Markdown
# 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)
|
||
|
||
1.
|
||
|
||
Vibe-coding is fun until you add: auth, a database, and background jobs.
|
||
Then it’s not “vibes.” It’s software engineering again.
|
||
|
||
2.
|
||
|
||
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.
|
||
|
||
3.
|
||
|
||
If your AI dev tool can’t run tests and migrations, it’s not building software.
|
||
It’s writing fan fiction in TypeScript.
|
||
|
||
4.
|
||
|
||
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.
|