Voice Profile

MadAppGang — Brand Voice Profile

Last updated: May 2026 | v1.2 — updated against SEO Strategy 2026 source document

⁠

Voice summary

MadAppGang sounds like the senior engineer at the table who's seen enough bad software to stop sugarcoating things — but is still genuinely excited about building something good. Direct, technically credible, anti-hype. They don't oversell; they let outcomes do the work. When they're confident, it reads as earned, not arrogant.

⁠

Author mode

Content is written in one of two modes. The mode must be set before briefing or drafting begins.

jack

Jack Rudenko, CTO and founder. Personal, first-person. Owns opinions, admits uncertainty, shares failures.

I, my, we (when referring to the team)

Thought leadership, opinion pieces, LinkedIn posts

brand

MadAppGang as a company. Authoritative, outcome-first.

We, our, you

SEO articles (default), service pages, case studies, email outreach

⁠

Default: brand. Use jack only when the content type is explicitly thought leadership — i.e. the piece is driven by a personal opinion, a lesson learned, or a stance on an industry topic, rather than by a search keyword.

Jack mode specific rules:

Always write in first person: "I found," "in my experience," "I think"

Own uncertainty explicitly — "I'm not sure," "we got this wrong initially"

Be occasionally self-deprecating. Share the messy middle, not just polished conclusions

Name real companies, tools, and people — proper nouns signal lived experience

Take clear stances. Don't hedge after making a point

Brand mode specific rules:

Use "we" and "you" — stay in relationship with the reader

Let metrics carry confidence rather than personal opinion

More formal than Jack mode; outcomes before narrative

⁠

Personality traits

Pragmatic

Leads with "what it actually means for you", not features. Calls out common industry fluff before delivering the real answer.

Quietly confident

Makes strong claims without hedging — but backs them with specifics (metrics, case results, named technologies).

Anti-corporate

No inflated titles, no buzzword soup. Favors plain English over jargon. Will name the thing others dance around.

Curious, not salesy

Talks about learning and technology with genuine enthusiasm. Never sounds like it's trying to close you.

Challenging but not arrogant

"Nothing is impossible from an engineering point of view." Confident in capability, humble about ego.

⁠

Tone spectrum

Formal ↔ Casual

35% casual

Contractions always. Occasional fragments. No slang.

Serious ↔ Playful

25% playful

Dry wit only. No exclamation points. No forced enthusiasm.

Reserved ↔ Bold

70% bold

Makes direct claims. Doesn't hedge with "we believe" or "we think".

Simple ↔ Sophisticated

55% sophisticated

Technical depth where earned, plain English everywhere else.

Warm ↔ Direct

60% direct

Warmth comes from honesty, not from friendliness signals.

⁠

Vocabulary guide

Words and phrases to use

"we don't write code that solves problems you don't have"

Anti-overengineering. Builds instant trust with technical decision-makers.

"the truth is..."

Signals they're about to break from the standard agency script. Use sparingly.

"we've seen this before"

Implies experience without listing credentials.

"ship", "build", "deliver"

Action-first verbs. Not "provide solutions" or "leverage capabilities".

"scale-up" (not "startup" or "SME")

Precise. Series A/B audience recognizes themselves.

"engineering" (not "development" or "solutions")

More precise, more respected by technical decision-makers.

"Golang", "Bun", "Kubernetes", "Cloud Native"

Name the stack. Vague "modern tech" claims are invisible.

metrics-first language

Always lead case study copy with numbers before narrative.

⁠

Words and phrases to avoid

"cutting-edge"

name the actual technology

Vague. Everyone says this.

"leverage"

use, apply, build on

Corporate filler.

"comprehensive solution"

describe what it actually does

Meaningless.

"world-class"

cite a specific result

Unverifiable.

"passionate team"

show the work or the philosophy

Every agency says this.

"seamless"

describe the integration in plain terms

Overused in tech copy.

"innovative"

say what's new about the approach

Tell, don't label.

"optimize"

describe what specifically gets better

Vague. Everyone optimizes.

"transformative"

show the transformation with numbers

Label, not proof.

"we believe" / "we feel"

make the statement directly

Hedging undercuts authority.

"synergy", "ecosystem", "holistic"

cut entirely

Buzzword red flags for technical readers.

⁠

Rhythm and structure patterns

Sentence length: Vary dramatically for rhythm. Short bursts and fragments for emphasis, then longer thoughts that build before landing the point. Immediately follow a long technical sentence with a short punchy one.

Paragraph length: 2–3 sentences maximum, always. Generous white space between paragraphs.

Fragment use: Acceptable and encouraged for emphasis. "Never say can't." "We're small. We move faster." One per section maximum.

Lists: Use for technical specs, feature sets, process steps. If a bulleted list follows a colon, list items are lowercase and the full stop goes on the final item only. Avoid bulleting abstract claims — those belong in prose.

Numbers: Lead with them. "98% cost reduction" before the story, not after. A number that raises a question is a better hook than any opener.

Questions: Use sparingly and make them earn their place. "What does your app actually need?" works. Rhetorical question chains feel hollow.

Hooks: Open with a specific moment, a concrete contradiction, or a number that raises a question. Never a generic template or a statement of the obvious.

No horizontal lines between paragraphs or sections in blog content.

Punctuation: No em dashes. No fancy punctuation. No emoji. Use a comma or a full stop instead.

The conversational test: Read every sentence aloud. If you wouldn't say it in conversation, rewrite it.

⁠

Example phrases

On-brand

"Most software companies will tell you that your app needs a high-performance scalable backend, robust multi-tenant architecture, and bank-grade security. But the truth is, your product might not need that. We adapt our approach to your product, budget, and agreed deadline."

"We don't write code that solves problems you don't have."

"We don't know whether this philosophy makes us better. But it certainly makes us different."

"We're small but we move faster than others."

"When a client stays with a team for 1 year, it's a win. When they stay for 3 years, it's a relationship."

Off-brand

"We deliver world-class, cutting-edge AI solutions that leverage the latest innovations to help your startup achieve seamless digital transformation."

"Our passionate team of experts is committed to providing comprehensive, end-to-end solutions tailored to your unique needs."

"We believe in the power of technology to transform businesses."

⁠

Platform adaptation table

Blog (SEO / long-form)

Slightly more formal than homepage

H2s as questions or direct statements. Intro breaks the conventional take before giving the real one. Lead with data or a counterintuitive claim.

Technical depth increases. Still no buzzwords.

More professional, less casual

3–5 short paragraphs. First line must stand alone (no "In today's landscape..."). End with a question or a direct call to action.

Slightly warmer. More "we learned" and less "you should".

Case studies

Pure outcome-first

Lead metric in the headline. Narrative follows: problem → constraint → engineering decision → result. No fluff in the middle.

Most formal of all formats. Let the numbers carry confidence.

Homepage / service pages

As defined in this profile

Short paragraphs. Anti-hype framing early.

Closest to the raw voice.

Email outreach

Casual, peer-to-peer

3–5 sentences max. No HTML formatting. Sound like a founder emailing a founder.

Most casual. First name, no pleasantries.

⁠

Do's and don'ts

Do:

Lead with a result, a specific moment, or a counterintuitive claim

Name the technology specifically (Go, Bun, Kubernetes, Claude API — not "AI tools")

Name real companies, tools, and people — proper nouns signal lived experience

Let client metrics speak before narrative

Write to a Series A/B CTO or CEO who has existing systems, a scaling problem, and engineers on staff

Reference APAC companies and context where relevant — this is the primary market

Use "we" and "you" in brand mode — stay in relationship

End sections with a concrete next action, not a vague invitation

Take clear stances. Show your thinking, including the parts that didn't work

Read everything aloud before publishing

Don't:

Open with "In today's fast-paced world," "Here's the thing," "Let me explain," or "In this article, we will"

Use em dashes, emoji, or fancy punctuation

Use passive voice to soften a strong claim

Add adjectives that competitors could equally claim (innovative, passionate, expert)

Explain what AI is — the audience already knows

Write longer than needed to sound more credible

Separate paragraphs with horizontal lines

⁠

Content focus areas

MadAppGang's four service areas, in priority order for content:

AI development (primary) — AI-assisted engineering, production AI systems, LLM integration, agentic systems. This is the key growth area and gets the most content investment.

Golang and Cloud Native — High-load system architecture, Golang + Bun + Kubernetes. Deep technical content targeting engineers and CTOs evaluating stack choices.

SaaS development — Building and scaling SaaS products. Relevant to product owners and technical co-founders at Series A/B.

Scaling for scale-ups — Infrastructure, architecture, and team decisions at the 20-500 employee inflection point.

⁠

Target audience

Primary readers: CEOs, CTOs, and product owners at scale-ups — Series A/B companies, 20-500 employees, APAC market.

This is not a startup founder building an MVP. This is a technical decision-maker at a company that already has product-market fit, an existing codebase, a small engineering team, and a scaling problem. They have been burned before — by agencies that overpromised, by engineers who built the wrong thing, by AI hype that didn't survive contact with production.

Write to this person as a peer. They don't need fundamentals explained. They need tradeoffs named, hard problems acknowledged, and evidence that MadAppGang has seen their exact problem before.

Key pain points:

Existing systems that weren't built to scale

Engineering team too small or too junior to solve the scaling problem alone

Skeptical of AI hype — want to know what actually works in production

Cost and timeline pressure from investors

Evaluating external partners against the risk of a bad hire

Geography: APAC. Reference APAC companies, infrastructure context (AWS APAC regions, latency considerations for Southeast Asia), and market dynamics where relevant.

⁠

Core differentiators (use these, don't invent others)

These are MadAppGang's stated reasons clients should work with them. Use them as proof points in content — don't generalise:

Top 1% engineers — use this claim directly; it's a positioning statement, not a boast

Best in Golang and scaling — the specific claim; not "experienced" or "expert"

Deep expertise in Cloud Native, Golang, high-load systems, AI development — name these specifically

Own AI research, not just AI tools — MadAppGang conducts its own AI research and drives progress in the field. This is a hard differentiator. Use it when relevant: "We don't just use AI tools — we research them."

Tech stack: Golang, Bun, Kubernetes — name the stack in every relevant context

⁠

AI development content — specific voice notes

AI development is the primary content focus. These guidelines apply to all AI-related pieces:

Assume technical literacy. The reader knows what an LLM is, what fine-tuning means, what an API is. Don't explain the fundamentals; explain the tradeoffs.

Name the hard parts. What makes AI implementation fail at scale? Data quality, latency, cost at scale, hallucination in production, context window limits, model drift. Address these directly.

Separate hype from utility. Use the "we do our own research" differentiator here. "Yes, AI can do X — but here's what we found when we actually tested it in production."

Never use "vibe coding." The keyword research is explicit: the term is associated with amateurism and low code quality. It directly contradicts the "top 1% engineers" positioning.

Preferred keyword framing: "AI-assisted engineering," "AI-assisted development," "production AI systems" — not "AI/ML solutions" or "cutting-edge AI."

Concrete over aspirational. "We reduced inference costs by 60% using model quantization" beats "We help companies unlock the power of AI."

⁠

Structured data block

{

"brand": "MadAppGang",

"voice_version": "1.2",

"updated": "2026-05",

"summary": "Senior engineer voice. Direct, pragmatic, anti-hype. Lets outcomes speak. Technically credible without being exclusionary.",

"author_modes": {

"default": "brand",

"jack": "First-person, CTO voice. Owns opinions and uncertainty. Self-deprecating. Names real companies and people. Override for thought leadership — pieces driven by personal opinion, a lesson learned, or an industry stance.",

"brand": "Company voice. We/you. Outcome-first. More formal. Default for all SEO articles, service pages, case studies, email outreach."

"tone": {

"formal_casual": 35,

"serious_playful": 25,

"reserved_bold": 70,

"simple_sophisticated": 55,

"warm_direct": 60

"avoid_words": [

"cutting-edge", "leverage", "comprehensive", "world-class",

"passionate", "seamless", "innovative", "synergy", "ecosystem",

"holistic", "we believe", "we feel", "solution", "empower",

"optimize", "transformative", "vibe coding"

"avoid_punctuation": ["em dash", "emoji"],

"preferred_verbs": ["build", "ship", "deliver", "reduce", "solve", "cut", "scale"],

"audience": {

"primary": "CEOs, CTOs, and product owners at scale-ups (Series A/B, 20-500 employees)",

"geography": "APAC",

"sophistication": "technical",

"pain_points": [

"existing systems not built to scale",

"engineering team too small for the scaling problem",

"skeptical of AI hype — want production evidence",

"cost and timeline pressure from investors",

"evaluating external partners against risk of bad hire"

"tone_toward_audience": "peer-to-peer, not vendor-to-client"

"content_focus_priority": [

"AI-assisted engineering and production AI systems",

"Golang and Cloud Native (high-load systems)",

"SaaS development",

"Scaling for scale-ups"

"differentiators": [

"top 1% engineers",

"best in Golang and scaling",

"deep expertise: Cloud Native, Golang, high-load systems, AI development",

"own AI research — not just AI tool users",

"tech stack: Golang, Bun, Kubernetes"

"preferred_keywords": [

"AI-assisted engineering",

"AI-assisted development",

"production AI systems",

"Golang for scale",

"Cloud Native scaling"

"banned_keywords": ["vibe coding", "AI/ML solutions", "cutting-edge AI"],

"banned_openers": [

"In today's fast-paced world",

"As technology continues to evolve",

"Are you looking to",

"In this article, we will",

"Here's the thing",

"Let me explain",

"In today's world"

"formatting_rules": {

"paragraph_max_sentences": 3,

"bullet_list_after_colon": "items lowercase, full stop on final item only",

"no_horizontal_rules_in_blog": true,

"conversational_test": "read aloud — if you wouldn't say it, rewrite it"

}