Production Package

Tell the Symph origin story through ONE specific project from the early days. Pick a project that was hard, that tested the team, that taught a lesson. The audience should think: "these people have been in the trenches."

• What Symph looked like in the early years (small team, big ambition, Cebu-based)
• A specific project that went wrong or was harder than expected
• What that project taught about building software that still matters today
• The moment when AI entered the picture and how it felt different from previous tech waves

• If your engineering is sloppy, AI makes it sloppier, faster
• If your engineering is solid, AI makes it faster AND better
• Example: a team with strong testing culture can use AI to write tests. A team without testing culture uses AI to ship untested code faster. Same tool, opposite outcomes.
• "AI is a multiplier, not a magic wand. It multiplies whatever you already are."

• After 16 years, the recurring pattern: projects fail because of misaligned requirements, not bad code
• AI can write code fast. It can't figure out what the client actually needs.
• Experience = knowing which questions to ask before writing a single line
• Example: a specific project where understanding the client's real problem (not stated problem) saved the engagement

• Every tech wave (mobile, cloud, microservices, now AI) came with "this changes everything"
• What actually changes: speed and capability. What doesn't change: the need for someone who's seen it go wrong.
• Specific example: we recently evaluated whether to use AI for a client's invoice processing system. The AI worked beautifully on the sample data. But we'd built enough financial systems to know: edge cases in payment processing don't show up in samples. They show up in production at month-end. We scoped the project differently because of that experience. A newer team would've shipped the demo and charged for the fix later.
• "We've been through enough cycles to know: the tool is never the hard part. Knowing when NOT to use the tool is."

Ask your AI partner: "What's the oldest project you've shipped?" If the answer is less than 2 years, you're their learning experience. That's fine if you want to pay for someone's education. It's not fine if you need production-grade.

Look at what they've built for themselves, not just for clients. Symph built ContractGen, HireAI, and Aria for internal use. That means we hit our own bugs, live with our own design choices, and fix our own production issues. If a company only builds for others, they don't feel the pain of maintaining software long-term.

AI speed without engineering discipline is just faster mistakes. Before you get excited about "we can ship in 2 weeks," ask: what's the testing strategy? What's the deployment pipeline? How do you handle production issues at 2 AM? Speed matters. Speed without infrastructure is dangerous.

The origin of Aria. Start with the problem: we were building AI products for clients but not using AI internally. The hypocrisy of selling AI while running on spreadsheets and Slack messages. The decision to "eat our own dog food."

• The "aha" moment: "If we're telling clients to adopt AI, why aren't we running on it ourselves?"
• The first thing Aria did (something small and specific)
• The first time Aria broke something (honesty builds credibility)
• What Aria does today that would take a human team member 10x longer

• Code generation and code review (first drafts, not final approval)
• Documentation and technical writing
• Data analysis and reporting
• Repetitive task automation (deploys, testing, monitoring)

• Design mockups and layout execution (AI generates options, a human with design judgment picks and refines)
• Client communication and relationship management
• Architecture decisions (AI suggests, humans decide)
• Creative direction and brand voice
• Conflict resolution and prioritization

• Understand unspoken client needs and politics
• Make judgment calls in ambiguous situations
• Build real trust with stakeholders
• Know when to push back on a bad requirement

Start with your most repetitive task, not your most important one. Pick something boring that eats hours. Deploy AI there. Prove it works. Then expand. Don't start with "let's replace our product manager with AI."

Give AI a role, not just a tool. When we treated AI as a tool ("use this to write emails"), adoption was low. When we gave Aria a role ("Aria is responsible for first-draft code review on every PR"), usage became automatic. Frame it as a team member with responsibilities.

Expect it to break. Plan for it. Aria has broken things. Deployed bad code. Sent wrong messages. That's not a failure of AI. That's what happens with any new team member. The question isn't "will it make mistakes?" It's "do you have guardrails for when it does?"

Tell the story of a project that failed (can be anonymized). The audience should recognize the pattern from their own experience. The punchline: it wasn't a technology failure, it was a process failure.

• The project looked great on paper (impressive proposal, good team, big budget)
• What actually happened: scope kept changing, the AI model was trained on wrong data, nobody defined success criteria upfront
• How much money and time was wasted
• "The technology wasn't the problem. The approach was."

• Here's a scenario you've probably lived: your CEO read an article about AI on a flight. Now there's a mandate to "do something with AI" by Q3. You've been handed a budget with no problem definition. Sound familiar?
• "We want AI" is not a business requirement. "We want to process invoices 80% faster" is. Companies start with the technology and look for problems to solve. Should be the opposite.
• AI-native approach: start with the $10-25K pilot. Prove value on ONE workflow. Then scale.
• "If you can't describe the ROI in one sentence, you're not ready to build."

• Companies hire a "data science team" and expect magic. But AI projects need engineering, design, AND domain expertise working together.
• Most AI agencies are less than 2 years old. They've never maintained software long-term.
• AI-native approach: the team that builds it also runs it. Engineers who've shipped 50+ projects know what breaks at scale.

• Traditional: 6-month discovery, 12-month build, 3-month "stabilization." By then the market moved.
• New AI agency: "We'll build it in a weekend!" Ships a prototype, not production software.
• AI-native approach: 3-week sprint to a working MVP. Not a prototype. Working software with real users. Then iterate.
• "The right timeline is fast enough to learn, slow enough to not break."

Before you approve any AI project, run it through 3 questions. We call it the 3P Checklist:

• Problem: Can you state the business problem in one sentence with a dollar value? "We spend $2M/year on X and 40% is automatable." If you can't write that sentence, you're not ready.
• Pilot: Can you prove value for under $25K on one workflow? Any partner who insists on $200K upfront before proving anything is either confident or reckless. Demand a pilot first.
• Production: Ask your vendor: "What's still running?" Not what they've built. What's maintained in production with real users for more than a year. That's where experience shows up.

Bring this to your next budget meeting. It covers the wrong problem, the wrong team, and the wrong timeline in three questions.

A real story where AI output looked perfect but was subtly wrong, and a human caught it. The punchline: the AI was confident, articulate, and completely wrong. The audience should laugh in recognition.

• Option A: Aria generated a complete client-facing UI. Technically correct, all components present, colors matched the design tokens. But it looked like every other AI-generated interface on the internet. No personality, no hierarchy, no opinion about what the user should do first. A designer opened it and said: "This is AI slop."
• Option B: Aria wrote marketing copy for a client proposal. The copy was polished, persuasive, and included a case study reference that didn't exist. It was plausible enough that it almost shipped. A human caught it in review because they knew Symph's actual project history.
• Option C: Aria analyzed client data and produced a report with confident conclusions. One of the data transformations silently dropped null values, skewing the percentages. The numbers looked reasonable. An engineer who'd worked with messy data for a decade spotted the pattern.

• The task seemed perfect for AI (data-heavy, repetitive, clear rules)
• The output looked good, maybe even better than a human's
• The subtle mistake that a human caught (wrong assumption, hallucinated data, edge case)
• What would have happened if nobody checked

AI can follow style guides. It can't develop taste. When a client says "make it modern," a senior engineer asks 5 follow-up questions. AI takes the instruction literally and produces something "modern" by the average of its training data. Design decisions, brand voice, knowing when something "feels off" but technically follows the rules. That's pattern recognition from thousands of lived experiences, not training data. AI doesn't know what it doesn't know.

This one surprises people. AI is great at individual tasks. It struggles to maintain consistency across a 6-month project with evolving requirements. A human remembers context, politics, prior decisions. They remember that the client's CEO hates blue, that the billing module was scoped out in week 3, that the API format changed after a late-night call in March. AI starts fresh every time unless you architect systems around it. We built an entire artifact dependency graph inside Aria specifically to solve this problem, and it still requires human oversight at every transition. If your project is longer than 90 days, this is the biggest risk you're not thinking about.

AI will do whatever you ask. A good engineer pushes back: "You're asking for X, but what you actually need is Y." That pushback comes from experience, empathy, and professional courage. AI has none of those. The willingness to say "this is a bad idea" has saved our clients more money than any feature we've built.

"Should we add this feature?" That's not a technology question. It's technology AND business AND user experience AND timeline AND cost, all at once. With constraints that contradict each other. AI gives you a reasonable answer for each domain independently. Humans hold all five in their head and make a decision that's suboptimal in every individual dimension but optimal overall. That's wisdom. You don't get that from a model.

Use AI for volume, humans for judgment. 100 first drafts? AI. Deciding which draft is right? Human. The combination is faster and better than either alone.

Never ship AI output without human review. Not because AI is bad. Because confident and wrong is worse than slow and right. Build the review step into your process.

The companies that win with AI are the ones that know its limits. If your AI partner says "AI can do everything," run. If they can tell you exactly which tasks AI owns and which tasks still need humans, that's someone who's actually used it in production.

A real scenario: a founder came in expecting to spend $200-300K based on traditional quotes. The AI-native approach delivered the same scope for significantly less. OR: a founder came in expecting $5K based on AI hype, and we explained why that's not real. Either story works.

• What the project was (keep it general enough to not reveal the client)
• What a traditional agency quoted (or would have quoted)
• What we actually delivered it for and why the cost was different
• WHERE the savings came from (specific: AI-generated code, automated testing, faster iteration cycles)

• One process, one workflow. 90 days. Prove ROI before committing more.
• Example: "We test multiple AI models on your real data. Not a generic demo. Your actual workflows, your actual edge cases. Clients who've done the pilot have seen ROI as high as 3-4x in year one."
• This is the starting point for anyone who's never done an AI project before.

• 3-week MVP. Working software, not a prototype. Real users from day one.
• This is where the AI-native advantage shows: a traditional agency would take 3-6 months for the same scope.

• Full product. Production-grade. Designed, built, deployed, and supported.
• The $500K project that's now viable at $80-150K because AI handles 60-70% of execution.

• Enterprise transformation. Multiple systems. Ongoing partnership.
• Anchor: traditional enterprise consultancies charge $500K-2M for this scope. A full-time internal team costs $50-100K/month.

• Changing requirements mid-build (scope creep is the #1 cost driver, AI or not)
• Complex integrations with legacy systems
• Regulatory compliance requirements (healthcare, finance)
• Custom AI model training (vs. using pre-built models)

• Clear requirements before starting (pilot first, then build)
• Standard tech stack (Next.js, Firebase, GCP: battle-tested, no surprises)
• AI-native delivery (60-70% of execution handled by AI)
• Silicon Valley caliber talent from Cebu (40-60% of US rates)

If someone quotes you less than $10K for a production AI product, ask what corners they're cutting. AI makes things faster, not free. Sub-$10K gets you a demo or a prototype, not production software. Know the difference before you sign.

Start with a pilot, not a project. $10-25K for 90 days. Prove the ROI on one workflow. Then use that data to justify the bigger investment. This is how smart companies de-risk AI spending.

Compare total cost, not hourly rate. A cheaper hourly rate that takes 6 months costs more than a higher rate that delivers in 3 weeks. AI-native delivery is faster, so even at the same rate, the total project cost drops 60-70%.

Tell a story about a time Symph was the vendor and a client asked a question that exposed a real weakness. Not a story about judging someone else. The whole episode is self-interrogation. Leading with a story about your own weakness earns more trust in 90 seconds than five slides of portfolio. Pick the specific moment in prep call. The more uncomfortable it is to tell, the better it works.

• Our answer: "We built Aria. She writes code, produces designs, manages projects. You've seen her on every episode of this show."
• Why this matters: anyone can sell AI. Few companies run on it. If your AI partner doesn't use AI internally, they're learning on your project.

• Our answer: "We have projects running for 10+ years. FindMyShots launched in 2016 and still serves 1.2M users."
• Why this matters: building is easy. Maintaining is hard. An agency that's 18 months old has never maintained anything in production.

• Our answer: tell a real example where Symph pushed back on a bad requirement or declined a project that wasn't a good fit.
• Why this matters: a vendor that says yes to everything either doesn't understand the problem or doesn't care about outcomes.

• Our answer: specific process. Who gets paged. What the response time is. How Aria helps diagnose issues faster.
• Why this matters: production incidents reveal whether a team is battle-tested or just good at demos.

• Our honest answer: teams that want a body shop (we're project-based, not staff augmentation). Highly regulated environments where we don't hold domain certifications, like FDA-regulated medical devices or tier-1 banking core ledger systems. Clients who want to outsource and disappear (we need collaboration, not a handoff).
• Why this matters: a company willing to disqualify itself is a company that cares about outcomes, not just revenue.

Ask every vendor these five questions. Copy them down. Send them in an email. Watch who answers directly and who dances around them. The answers tell you more than any proposal ever will.

Beware the vendor who has no weaknesses. Every company has limitations. A partner who can't name theirs either doesn't know or won't tell you. Both are bad.

The best vendor evaluation is a small project, not a big meeting. Pay for a pilot. Watch how they communicate, how they handle problems, how fast they move. A $10-25K pilot tells you more about a partner than any RFP process.