<p>Something is broken.</p><p>Every company in the world is sitting on top of processes built for a different era. Slow, manual, designed for humans doing repetitive work because there was no alternative.</p><h3>There is now.</h3><p>And yet most companies are still stuck. Not because they don't know AI exists. They've seen the demos. They've read the headlines. Some have even run the pilots.</p><p>But knowing AI exists and actually using it to change how your business runs are two completely different things.</p><p>That gap is costing companies millions of hours a year. And it is entirely unnecessary.</p><p>We built LayerX to close it.</p><h3>Here is what that looks like.</h3><p>We work with companies in three ways.</p><h4>AI Consultancy</h4><p>We sit with your team, understand how your business actually runs, and figure out where AI makes a real difference. Not where it sounds impressive. Where it actually changes something. Then we design it, build it, and help you ship it. That could mean automating a process that is eating 20 hours a week. Or embedding intelligence into a product your customers already use.</p><h4>AI-Powered Products</h4><p>We keep building our own products, but now with AI woven into the foundation. These are not tools with a chatbot bolted on. They are built from scratch to be faster and more useful in the real scenarios companies face every day.</p><h4>AI Workshops and Programs</h4><p>Most AI training is slides and theory. Ours is not. We run hands-on sessions where teams work with real problems from their own business. They walk out knowing how to use AI, not just what it is. Through TAIKAI, our hackathon platform, that learning turns into working prototypes, tested ideas, and new internal tools.</p><h3>What we are building toward.</h3><p>Every company we work with teaches us something. Where AI breaks down in the real world. Where the tools fall short. Where the gap between what is possible and what is actually deployed is widest.</p><p>That knowledge compounds. And over time, it becomes the foundation for something bigger than consulting.</p><p>We are building the European team that closes the gap between AI research and real business impact. Not with hype. With work.</p><p>The result is not a demo. It is a different company.</p><p><strong>If yours is ready, <a href="https://tally.so/r/waVKK9" target="_blank">let's talk</a>.</strong></p>

We're becoming the team that helps companies wire intelligence into what they already do.

LayerX: The team that makes AI work inside your business

<p>If you've worked in a growing company, you know how it goes. The product keeps evolving, more users show up, and at some point the support inbox becomes this endless thing. The same questions keep coming in, and the team is stretched thin trying to answer everyone while also building the product. That was us at TAIKAI.</p><p>So we decided to do something about it.</p><h2>It started with a simple question</h2><p>The idea didn't come from a brainstorming session or a product roadmap. It came from the day-to-day. Our support team was spending way too much time answering the same questions over and over. "How do I submit my project?", "How do teams work?", "What are KAIs?", "Where can I find the results?". You get the picture.</p><p>We looked at what was out there. There are plenty of customer support tools with AI baked in. But most of them start at over $100 per month, and that's just the base plan. For a startup like TAIKAI, that adds up quickly when you're being careful about where every euro goes.</p><p>So we asked ourselves: what if we just build our own? We had the engineering team, we knew our product better than any third-party tool ever would, and with the AI models available today, running our own thing would cost a fraction of what we'd pay for something off the shelf. Maria runs for less than $5 per month. Five. Dollars.</p><p>Cost wasn't the only driver, though. We didn't want one of those chatbots that spits out canned responses and makes people feel like they're talking to a wall. We wanted something that understood context, that knew TAIKAI inside out, and that still felt like talking to a real person. Building it ourselves gave us full control over that.</p><h2>From hackathon idea to product</h2><p>Like many things at TAIKAI, the project started small. And in a very fitting way. The first version was born during one of our internal hackathons. Someone pitched the idea of a support bot, the team got excited, and in a few hours we had a working prototype answering basic questions on Telegram. A minimum viable experiment to see if the idea had legs. It did.</p><p>We saw the potential pretty quickly and decided to turn it into an actual product. But we also realized Telegram alone wasn't going to cut it. Our community lives on Discord, users interact with us through the platform itself, and we needed something that could work across multiple channels. So instead of building a bot for one platform, we'd build an API-first support system that could plug into anything.</p><p>That's how we went from a hackathon prototype to a proper support engine. We called her Maria, a name that felt right for who we are and where we come from.</p><p><span class="fr-video fr-deletable fr-rv fr-fvc fr-dvb fr-draggable"><iframe src="https://www.youtube.com/embed/4ttaTEVCSaY?autoplay=1&amp;mute=1&amp;wmode=opaque&amp;rel=0" frameborder="0" allowfullscreen class="fr-draggable"></iframe></span><br /></p><h2>How does Maria actually work?</h2><p>I'll keep this light.</p><p>Maria has a knowledge base at her core. A curated collection of questions and answers about TAIKAI: the platform features, hackathons, submissions, teams, all of it. When someone sends a message, she doesn't scan for keyword matches. She understands the meaning behind the question and finds the most relevant answers from what she knows.</p><p>If you ask "How do I join a team?" or "I want to be part of a group", Maria gets that both questions are about the same thing, even though the words are completely different. That's semantic search. Intent over exact wording.</p><p>She also remembers the conversation. If you asked something two messages ago, she keeps that context. It makes the whole thing feel like an actual conversation, not a form you're filling out.</p><h2>A peek under the hood</h2><p>For those curious about the tech side, here's how the pieces fit together.</p><p>Maria runs as her own service, built with TypeScript and Node.js. She sits behind an API, which is how both our main platform and the CMS communicate with her. When a user sends a message, it goes through this API, gets processed, and the response streams back in real time. No waiting around for a full answer before anything shows up on screen.</p><p>For data, we use PostgreSQL to store conversations, sessions, and the knowledge base. Redis takes care of the fast operations like rate limiting and tracking active sessions. The AI part connects to large language models through OpenRouter, which lets us swap between different models depending on what performs best.</p><p>The knowledge base is where it gets interesting. Each Q&amp;A pair lives in the database alongside its vector embedding, a numerical fingerprint of its meaning. When someone asks a question, Maria turns it into the same kind of fingerprint and looks for the closest matches. That's how she finds the right answers even when the phrasing is totally different from what's stored.</p><p>Everything connects through a session system. Each conversation gets its own session with full message history, so Maria always knows where things left off. When Discord is involved, threads link directly to sessions, so our human agents can pick up the same conversation without missing anything.</p><p>The architecture is simple. It does what we need, and that was the goal.</p><h2>Knowing when to step aside</h2><p>This was important for us from the start: Maria had to know her limits. Not every question has a clean answer, and not every situation can be solved by an automated system. We've all been stuck talking to a bot that keeps looping with irrelevant responses when you clearly need a human. We didn't want that.</p><p>So we built a confidence system. Every time Maria generates a response, she scores how confident she is in it. If that score drops below a certain point, she stops trying. She escalates to a human agent and sends an alert to our team on Discord with the full conversation, so whoever picks it up already has all the context.</p><p>We'd rather Maria say "Let me get someone from the team to help you" than give a wrong answer. Trust takes a long time to build and very little to break.</p><h2>Building it piece by piece</h2><p>The project grew through iteration. We didn't design the whole system upfront. We started with the basics, tested, learned, and kept going.</p><p>It began with the hackathon prototype on Telegram. From there we built a proper API with session management and conversation memory. Semantic search came next to make answers more accurate, followed by Discord integration so the team could step in when needed. We added rate limiting to keep things stable and made the knowledge base easy to update so it could grow alongside the platform.</p><p>Every step came from a real need. We never added something because it sounded cool or because someone else was doing it. Each feature had to earn its place.</p><h2>What we learned along the way</h2><p>Building Maria taught us a few things beyond the technical stuff.</p><p>The hackathon prototype was a simple experiment, but the vision was always bigger. Starting small let us validate the idea without overcommitting. Having that bigger picture in mind helped us make better decisions when it came time to grow.</p><p>The knowledge base turned out to be the most important piece. The best AI model in the world can't help if it doesn't have the right information. We spent real time curating and organizing Q&amp;A pairs, and that effort showed directly in the quality of Maria's responses.</p><p>We used to see escalation to humans as a limitation. Over time it became clear that it's a feature. It builds trust with users and shows us exactly which questions the knowledge base doesn't cover yet, so we can keep improving.</p><p>And giving the project a name mattered more than we expected. Once we started calling her Maria, people on the team talked about her like a colleague. That sense of identity helped everyone take ownership.</p><p><span class="fr-video fr-deletable fr-rv fr-fvc fr-dvb fr-draggable"><iframe src="https://www.youtube.com/embed/ikjAa9ulwF4?autoplay=1&amp;mute=1&amp;wmode=opaque&amp;rel=0" frameborder="0" allowfullscreen class="fr-draggable"></iframe></span><br /></p><h2>What's next for Maria</h2><p>Maria already helps our users every day, but there's a lot more we want to do. Right now she knows TAIKAI as a whole: the platform, the features, the common questions. But what if she knew you? What if she knew which hackathon you're in, what projects you've submitted, what stage you're at?</p><p>We want to connect Maria to the TAIKAI API so she has real context about who she's talking to. Imagine asking "How do I submit my project?" and instead of a general answer, Maria knows your specific hackathon, checks if submissions are still open, and walks you through the exact steps for that challenge. Or a customer on the CMS asking about event settings, and Maria already knows which challenge they manage and what's configured.</p><p>Going from a support assistant that knows the platform to one that knows your situation. We also want her to learn from every interaction, growing the knowledge base automatically from conversations our human agents have with users.</p><p>We never set out to replace human support. The goal was to free up the team for the conversations that actually need a person, while Maria handles the repetitive stuff. So far, that's what's been happening.</p><p>Today Maria lives in two places: on our main platform, where hackers and users interact with TAIKAI, and on our CMS, where the companies and organizations running challenges manage their events. Each side has its own context. Maria knows where she is and adjusts accordingly. A hacker asking how to submit a project gets different answers than a customer asking how to set up their challenge. Same Maria, different knowledge.</p><p>If you're part of the TAIKAI community, there's a good chance you've already talked to her. If not, say hi next time you have a question.</p>

How TAIKAI built an AI support agent for under $5/month — from internal hackathon idea to product, replacing tools that cost over $100/month.

Meet Maria: How We Built a Support Agent That Actually Knows TAIKAI

<p>In the past few months I evaluated more than 30 business ideas for LayerX. Some went to production. Most didn't. The problem wasn't lack of ideas. It was lack of rigor. Evaluating ideas takes time, and when you're a small studio juggling multiple products, you rarely have the bandwidth to go deep on every concept.</p><p>So I built a Venture Analyst agent in Claude. Not a chatbot that gives you "great idea!" feedback. A structured analyst that thinks like a VC, plans like an operator, and kills bad ideas before they waste your team's time and capital.</p><p>Here's how it works, and how you can build your own.</p><p><br /></p><div><div><br /></div></div><h3>What Is a Claude Skill?</h3><p>Before diving in, a quick explanation. A Claude skill is a .md file you upload to a Claude Project as knowledge. When Claude has access to it, you can instruct the agent to "run Skill 03" and it executes a specific analytical framework with structured outputs, scoring, and transitions to the next step.</p><p>Skills are modular. They chain. They build on each other. And when you sequence 10 of them, you get a full venture analysis pipeline that rivals what a junior VC analyst would take a week to produce.</p><div><div><br /></div></div><p><br /></p><h3>The Venture Analyst Agent</h3><p>The agent operates from a core system prompt that defines its role, behavioral rules, and operating logic. The profile is a hybrid:</p><ul><li>McKinsey consultant for structured, evidence-based reasoning and clean deliverables</li><li>VC analyst for honest kill assessments, unit economics rigor, and deal logic</li><li>Operator for resource constraints and capital-efficient thinking</li></ul><p>It applies 6 strategic filters to every idea before running the full pipeline:</p><ul><li>Capital Efficiency: MVP + first 10 customers for under €50K</li><li>Time to Signal: market validation within 60-90 days</li><li>B2B Focus: selling to businesses, not consumers</li><li>Asset Leverage: must activate at least one existing company asset</li><li>Revenue Path: realistic path to €5K-20K MRR within 12 months</li><li>Portfolio Fit: strengthens the portfolio, doesn't cannibalize it</li></ul><p>If an idea fails 2+ filters at the first skill, the agent flags it immediately and doesn't waste cycles running a full pipeline.</p><div><div><br /></div></div><p><br /></p><h3>The 10 Skills</h3><h4>Skill 01: Idea Clarity &amp; Scoping</h4><p>The entry gate. Transforms a raw idea into a structured Idea Brief with a problem-solution hypothesis, initial ICP sketch, and assumptions to validate. If the idea is too vague, the agent asks 3-5 targeted clarifying questions instead of guessing.</p><p>Output: Idea Brief + Clarity Score (1-5)</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-01-idea-clarity-scoping.md" target="_blank">Download Skill 01 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 02: Market Sizing &amp; Analysis</h4><p>No more "the market feels big." This skill builds a TAM/SAM/SOM using both top-down and bottom-up approaches, calibrated to European market data. It assesses market dynamics, timing, and growth rate.</p><p>Output: Market Sizing Brief with TAM/SAM/SOM figures and Market Attractiveness Score</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-02-market-sizing-analysis.md" target="_blank">Download Skill 02 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 03: Customer Discovery &amp; Validation Design</h4><p>Defines the Ideal Customer Profile in three layers: firmographic, psychographic, behavioral. Maps the pain hierarchy (Level 1-4), Jobs-to-Be-Done, and designs 3-5 validation experiments with success criteria before you spend a cent.</p><p>Output: Customer Discovery Brief + Validation Experiment Designs</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-03-customer-discovery.md" target="_blank">Download Skill 03 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 04: Competitive Landscape Mapping</h4><p>Identifies direct, indirect, and adjacent competitors. Builds a 2x2 positioning matrix, maps competitor blind spots, and defines where the company's sustainable competitive advantage actually sits. Finds the white space.</p><p>Output: Competitive Landscape Map + Strategic Positioning Recommendation</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-04-competitive-landscape-mapping.md" target="_blank">Download Skill 04 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 05: Business Model &amp; Unit Economics Design</h4><p>Selects the revenue model architecture, designs pricing tiers, and calculates the full unit economics stack: CAC, LTV, payback period, margins. Builds a 12-month revenue projection across base, bull, and bear scenarios. Stress-tests every assumption.</p><p>Output: Business Model Blueprint + Unit Economics Scorecard + 12-Month Projections</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-05-business-model-design.md" target="_blank">Download Skill 05 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 06: Risk Assessment (VC Lens)</h4><p>Scans 9 risk categories the way a VC due diligence team would: Market, Customer, Competition, Technology, Business Model, Execution, Financial, Regulatory, and Strategic Fit. Scores each on likelihood x impact. Identifies "Kill Risks" - existential threats that must be validated before you proceed.</p><p>Output: Risk Assessment Matrix + Kill Risk List + Mitigation Playbook</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-06-risk-assessment.md" target="_blank">Download Skill 06 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 07: Strategic Fit Filter</h4><p>This is where most generic frameworks fall apart. A great idea for someone else can be a NO GO for your company. This skill evaluates the idea against your specific assets, constraints, and portfolio. Not in the abstract. Capital Efficiency and Time to Signal are double-weighted.</p><p>Output: Strategic Fit Assessment (/40) + Asset Leverage Analysis + Build/Partner/Pass Recommendation</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-07-strategic-fit-filter.md" target="_blank">Download Skill 07 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 08: GO / NO GO Decision Framework</h4><p>The synthesis. Compiles evidence from all prior skills, applies a hard kill-risk gate, runs a weighted decision matrix across 8 dimensions, and delivers a clear verdict: GO, CONDITIONAL GO, or NO GO. Includes bull/bear cases and execution guardrails.</p><p>The agent is instructed to kill bad ideas clearly. No softening a NO GO into a CONDITIONAL GO to avoid discomfort.</p><p>Output: Decision Document with Verdict + Execution Guardrails + Kill Criteria</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-08-go-no-go-decision.md" target="_blank">Download Skill 08 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 09: Go-to-Market Strategy</h4><p>Only runs after a GO or CONDITIONAL GO verdict. Designs the full launch plan: positioning, phased acquisition strategy (Validation → First Revenue → Growth), channel-by-channel plan, launch sequence, sales process, and a 90-day execution calendar with weekly actions and budget allocation.</p><p>Output: GTM Playbook + 90-Day Calendar + Budget Allocation</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-09-go-to-market-strategy.md" target="_blank">Download Skill 09 →</a></p><p><br /></p><div><div><br /></div></div><h4>Skill 10: Adjacent Opportunity Discovery</h4><p>The pipeline doesn't stop at launch. This skill scans 6 adjacency dimensions (same customer/different problem, same problem/different customer, platform plays, value chain expansion, geographic expansion, business model innovation) and scores adjacent opportunities to build your exploration pipeline.</p><p>Output: Adjacent Opportunity Map + Scored Opportunity Table + Portfolio Integration Matrix</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/skill-10-adjacent-opportunity-discovery.md" target="_blank">Download Skill 10 →</a></p><p><br /></p><div><div><br /></div></div><h3>How to Set It Up</h3><ol><li>Create a new Claude Project</li><li>Add the Company Context skill to project knowledge (your company's assets, products, and strategic direction; the agent references this constantly). Feel free to use Claude chat to help you create this one.</li><li>Upload all 10 skill files to project knowledge or to Claude directly (Customize tab)</li><li>Paste the your Venture Analyst system prompt as the project's custom instructions. Make sure it has your company context and feel free to use the content of this article to help you set it up.</li><li>Start pitching ideas</li></ol><p>You can run the full pipeline sequentially or jump to specific skills. The agent handles both modes.</p><div><div><br /></div></div><p><br /></p><h3>What It Actually Produces</h3><p>When you pitch an idea, you get:</p><ul><li>A structured Idea Brief</li><li>A market sizing with real numbers</li><li>An ICP with validated pain hierarchy</li><li>A competitive map with your positioning</li><li>Unit economics with 12-month projections</li><li>A scored risk matrix with kill risks flagged</li><li>A company-specific strategic fit assessment</li><li>A clear GO / NO GO verdict</li><li>A 90-day GTM calendar (if GO)</li><li>An adjacent opportunity map for what to build next</li></ul><p>That's what a consulting team charges €50K to produce. The agent does it in one session.</p><div><div><br /></div></div><p><br /></p><h3>One Important Note</h3><p>The agent is only as good as your Company Context skill. That file is the foundation. It defines your assets, your portfolio, your constraints, your team. Keep it updated. When you launch a new product or change strategic direction, update the skill. The agent references it on every analysis.</p><p>The skills are available for download below. Adapt the Company Context template to your own company, drop in the system prompt, and you're running.</p><p><a href="https://storage.googleapis.com/taikai-storage/others/blog-post-assets/claude-skills/venture-pipeline-skills.zip" target="_blank">Download ZIP file with all skills →</a></p><p><strong>Install through Skills.sh</strong>: <em>npx skills add hypermari0/venture-analyst-skills </em> </p><div><div><br /></div></div><p><em>I'm Mário Alves, CEO of </em><a href="https://layerx.xyz" target="_blank"><em>LayerX</em></a><em>, an AI-powered studio based in Porto. We're a small team and we can't afford to chase the wrong ideas. This framework is how we keep that discipline.</em></p>

I built a 10-skill analytical framework in Claude that evaluates business ideas with VC-grade rigor.

McKinsey-Grade Venture Analyst in Claude Using 10 Custom Skills

How I Built a McKinsey-Grade Venture Analyst in Claude Using 10 Custom Skills

<p>I have a confession: I'm a business guy. Economics background. Former investment banker. I've spent my career on the strategy side, never writing a line of production code.</p><p>But this week, I shipped products.</p><p>Real products. Functional software. Things that actually work.</p><p>And I did it using AI coding tools. What some people are calling "vibe coding."</p><p><br /></p><h3>The Tools I Tried</h3><p>Over the past few weeks, I've been experimenting with three different approaches:</p><p><strong>v0</strong> is Vercel's AI design tool. Great for spinning up landing pages quickly. If you need a marketing site or a simple UI, it gets you 80% of the way there fast.</p><p><strong>Clawdbot </strong>is an AI assistant I deployed on an AWS server with Telegram integration. Setting this up taught me more about SSH tunnels, Cloudflare, and API configurations than I ever expected to learn.</p><p><strong>Claude Code</strong> is where things got interesting.</p><p><br /></p><h3>Why Claude Code Won</h3><p>Here's the honest truth: v0 and Clawdbot are useful tools. But Claude Code gave me something different. Freedom.</p><p>With Claude Code, I'm not constrained to templates or pre-built workflows. I can describe what I want in plain language, iterate on it, debug issues, and ship real software.</p><p>Is the code perfect? Probably not. Would a senior developer do it differently? Almost certainly.</p><p>But it works. And I built it.</p><p><br /></p><h3>What I Actually Shipped</h3><h4>1. LayerX Control Tower</h4><p>I run LayerX, and we needed a better way to visualize our financial health across multiple entities, bank accounts, and crypto wallets.</p><p>Instead of waiting for our dev team's availability, I built a financial control tower myself. A multi-page dashboard for tracking revenue, expenses, runway, and treasury positions.</p><p>It's now a finished product. Our employees, accountants, and auditors are already using it.</p><p>Could I have paid someone to build this? Yes. But by building it myself (with AI assistance), I understand every design decision. I can iterate instantly. And I shipped the whole thing in days, not weeks.</p><h4>2. Polymarket Trading Bot</h4><p>This one pushed me to my limits.</p><p>I wanted to automate trading on Polymarket, a prediction market platform. The bot is now fully configured with a dashboard to monitor all my trades in real time.</p><p>Here's the funny part: the trading strategy I chose lost me money.</p><p>But that's the beauty of building it myself. I'm not stuck. I'm already switching to a different strategy, tweaking the parameters, and testing new approaches. That kind of iteration would normally require going back and forth with a developer for weeks. Instead, I just... do it.</p><p><br /></p><h3>The Mindset Shift</h3><p>The hardest part wasn't the technical learning curve. It was giving myself permission to build.</p><p>For years, I'd had ideas and passed them to developers. Now I catch myself thinking: "Wait, can I just try building this myself first?"</p><p>Sometimes the answer is no. Some things genuinely need experienced engineers. But often the answer is: "Actually, maybe I can."</p><p><br /></p><h3>What This Means for Non-Technical Founders</h3><p>We're entering an era where the barrier between "idea person" and "builder" is collapsing.</p><p>This doesn't mean engineers are becoming obsolete. Far from it. The best software still needs experienced developers who understand architecture, security, and scale.</p><p>But it does mean that founders, product managers, and business people can now:</p><ul><li>Prototype ideas before involving engineering</li><li>Build internal tools without competing for dev resources</li><li>Have more informed technical conversations</li><li>Ship MVPs to test market demand</li></ul><p>The question isn't "Can I code?" anymore.</p><p>It's "What can I ship this week?"</p><p><br /></p><h3>My Challenge to You</h3><p>If you're a non-technical founder or executive who's been curious about these AI coding tools, just try it.</p><p>Pick something small. A landing page. An internal dashboard. A simple automation.</p><p>You'll make mistakes. You'll get frustrated. You'll probably break something.</p><p>But you'll also ship something. And that feeling of creating something from nothing, even with AI assistance, is addictive.</p><p>What are you going to build this week?</p><p><br /></p><p><em>I'm Mario, CEO of LayerX, the web3 studio behind TAIKAI. I write about building in web3, network states, AI tools, and what it's like to run a startup. Connect with me if you're also learning to vibe code.</em></p>

A non-technical CEO's honest guide of shipping real products using AI coding tools.

I'm a CEO Who Can't Code. Here's What I Shipped This Week.

A non-technical CEO's honest guide of shipping real products using AI coding tools. 

<p>Exchanges have become the mob bosses of crypto. They act like they run the streets, setting arbitrary prices, demanding “fees” for basic services, and punishing anyone who doesn’t play by their rules.</p><p>When I first entered this space, crypto was about freedom: taking power away from centralized institutions. Ironically, a handful of centralized exchanges (CEXes) have rebuilt the same system we were trying to escape.</p><h3>How CEXes Bleed You Dry</h3><p>Ask any project founder or token issuer, and you’ll hear the same horror stories. Listing a token costs anywhere between <strong>$50,000 and $500,000</strong>, sometimes even more. In return? You get erratic communication, slow integrations, and unprofessional support teams that treat multimillion-dollar projects like spam callers.</p><p>Need to change a token name or logo after a rebrand? That’ll be another <strong>$50k “service fee.”</strong> It's like dealing with a mafia that demands payment every time you repaint your storefront. Projects comply because liquidity matters and these exchanges know it.</p><h3>A Personal Lesson: The BEPRO → LX Rebrand</h3><p>At <strong>LayerX</strong>, we recently rebranded our token from <strong>BEPRO to LX</strong> to align it better with our ecosystem (TAIKAI, Bepro Network, TAIKAI Garden). We approached the exchanges where BEPRO was listed, in this case, <strong>KuCoin</strong> and <strong>Gate.io</strong>, to make the change.</p><p>The response? Each demanded around <strong>$50,000</strong> to update a name. Just a name. No new token contract, no migration, no smart contract work. When we refused, they cut off deposits, making it impossible to maintain healthy market liquidity.</p><p>Moments later, <strong>Gate.io delisted the token entirely with no warning, no call, nothing.</strong> A one-line telegram message, written in broken English, sealed years of community building. Days after that, <strong>KuCoin followed suit</strong>, claiming “security reasons” because liquidity was low on Gate. You can’t make this up.</p><p>Two billion-dollar companies, two five-minute decisions, and zero accountability.</p><h3>The Bigger Problem</h3><p>This isn’t just about one project. It’s about control.<br />CEXes have become the new middlemen, <strong>siphoning value from users and projects alike</strong>. They disguise it as “listing fees” or “liquidity incentives,” but the truth is: they’re taking rent from innovation.</p><p>We’re supposed to be building an industry that empowers open participation, transparency, and trust. Instead, we’ve recreated the same perverse incentives that made people lose faith in banks.</p><h3>The Way Forward</h3><p>For me, the message is clear: <strong>never again</strong>.<br />From now on, our focus is on <strong>decentralized exchanges (DEXes)</strong>, where markets are open, onchain, and permissionless. No gatekeepers, no backroom deals, no five-minute delistings.</p><p>This isn’t just a LayerX strategy; it’s a call to the entire industry. If we want crypto to thrive, we need to stop feeding the beasts that are actively killing it.</p><p>Withdraw your funds.<br />Support open protocols.<br />Let centralized exchanges fade into irrelevance. Where they belong.</p><h3>A Note on Regional Differences</h3><p>Not all centralized exchanges operate this way. My experiences have been mostly with <strong>Asian exchanges</strong>, where communication and professional standards are, frankly, disappointing.</p><p>However, I genuinely believe that <strong>US-based exchanges like Kraken or Coinbase</strong>, and <strong>European ones such as Bitvavo</strong>, uphold far higher standards in transparency, compliance, and professionalism. They’ve demonstrated that you can run a serious exchange business without resorting to exploitative practices.</p>

Centralized exchanges have become the mob bosses of crypto. 

Big Broker Is Watching You: Why You Should Leave CEXes Now

Big Broker Is Watching You: Why You Should Leave CEXes Before It’s Too Late

<h4>The LayerX token transition is officially live.</h4><p>$BEPRO is now $LX, becoming the single token that represents the entire LayerX ecosystem.</p><p>To support this transition, TKAI holders can now swap TKAI for LX at a fixed ratio.</p><h4>Swap details</h4><ul><li>Swap ratio: 1 TKAI = 10 LX</li><li>Networks supported: Base and Ethereum</li><li>Status: live</li><li>Swap page: <a href="https://swap.layerx.xyz/" target="_blank">https://swap.layerx.xyz/</a></li></ul><p>If you encounter any issues, please report to the team via <a href="https://discord.gg/layerx" target="_blank">Discord</a>, <a href="https://t.me/LayerX_Labs" target="_blank">Telegram</a> or at hello@layerx.xyz.</p><h4>To keep in mind</h4><p>No new token was created. $LX is the continuation of $BEPRO, now unified under the LayerX brand. </p><p>This swap consolidates LayerX into one token, aligned with our full product portfolio, present and future.</p><p>As LayerX grows, LX is designed to reflect the value and activity of the entire ecosystem, not individual products.</p>

The LayerX token transition is officially live.

$TKAI to $LX swap is live

<h3>The autocomplete era: late 2024 ⌨️</h3><p>At LayerX, we started experimenting with Cursor at the tail end of 2024. Initially, it felt like a productivity boost smarter autocomplete, faster boilerplate generation, and the occasional snippet that saved us a few minutes of typing. We were impressed, sure, but it still felt like a tool that accelerated what we already knew how to do. The AI was a Capable Assistant, filling in the blanks, but we remained firmly in the driver's seat for every meaningful decision.</p><h3><br /></h3><h3>The reasoning revolution: When models learned to think 🧠</h3><p>Then the reasoning models arrived, and everything shifted. When OpenAI released o1 and Anthropic introduced Claude Sonnet with its deeper contextual understanding, we weren't just getting code suggestions anymore, we were getting architecture and design advice. These models could reason through complex trade-offs, spot edge cases we'd missed, and propose solutions that required genuine understanding of our codebase and constraints.</p><p>Suddenly, our pair programming sessions weren't just faster; they were fundamentally different. The AI had evolved from a glorified autocomplete into something closer to a <strong>thoughtful collaborator</strong>, capable of tackling the kind of nuanced engineering challenges that previously demanded senior expertise and extended deliberation.</p><p>As our reliance on coding agents deepened, we noticed a subtle but profound transformation in how we approached our daily work. Co-programming with AI became our <strong>default mode</strong>, not as a novelty, but as a genuine force multiplier. Tasks that once stretched across days now wrapped up in hours. Bug fixes that required careful archaeology through legacy code became faster to diagnose and resolve. The precision improved too; with an AI partner that never tired and could hold vast coding and architecture context in memory, we caught edge cases earlier and wrote more robust and optimized implementations in from the start.</p><p><br /></p><h3>Guardrails against technical debt 🛡️</h3><p>But we weren't naive about the risks. The conversation around AI-generated code often circles back to the same concern: <strong>Technical Debt</strong>. </p><p>Critics warn that AI produces "junior code", functional but shallow, riddled with shortcuts that accumulate into maintenance nightmares.</p><p>We took this seriously. Rather than blindly shipping whatever the agent produced, we transformed not just how we write code, but how we govern it. We introduced guardrails that prevented AI-generated code from touching production without rigorous review.</p><p>Every pull request went through deliberate refactoring sessions, where we questioned structure, naming, organization, design patterns , and long-term maintainability.</p><p>Perhaps most importantly, we learned to front-load our collaboration: long planning sessions with the agent before a single line was written,discussing architecture, exploring trade-offs, and aligning on design principles.</p><blockquote><p>“In 2025 an Agentic AI Coder became a thinking partner first, a code generator second.”</p></blockquote><p><img src="https://taikai.azureedge.net/6uizxiJSD-W9myh_DNkFqWccfOFw3x2d44lpfARmRuw/rs:fit:800:0:0/aHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3RhaWthaS1zdG9yYWdlL2ltYWdlcy8wMjUwMDVjMC1kYTZiLTExZjAtYTE4Ny1jN2E2NGI0YTJjZmVjb3ZlcjIucG5n" style="width:391px" class="fr-fic fr-dib" /></p><p><br /></p><h3>Terminal-based agents: Claude Code 💻</h3><p>The next leap came when we started experimenting with terminal-based coding agents like Claude Code.</p><p>Honestly, we were skeptical at first. After years of relying on the comfort of IDE-driven development, syntax highlighting, inline suggestions, visual debugging, and all the familiar affordances, dropping into a terminal felt like a step backward.</p><p>Why would we abandon the rich tooling we'd spent years mastering for a command-line interface? But after a few sessions, something clicked. The terminal stripped away distractions and forced a different kind of focus. Conversations with the agent became more deliberate, more structured.</p><p>We found ourselves articulating problems more clearly, because we had to. There was no UI to lean on, no quick mouse click to bail us out. The agent's responses felt more cohesive too, as if the constrained environment encouraged deeper reasoning rather than scattered suggestions. Within weeks, what had seemed like a regression became our preferred way of coding. The terminal wasn't limiting us; it was sharpening us. Claude Code became the default mode for how we interacted with our codebase, whether exploring unfamiliar modules, refactoring sprawling functions, or architecting new features from scratch.</p><h4>Extensibility that scales with us</h4><p>What truly set Claude Code apart was its extensible architecture. Unlike closed systems that forced us to work within rigid boundaries, Claude Code allowed us to create our own subagents, specialized assistants tailored to our specific workflows. We built custom tools for our daily rituals: agents that understood our deployment pipelines, others fine-tuned for our smart contract auditing process, and some dedicated to navigating the intricacies of our github repositories. The platform became a foundation we could mold, not a box we had to fit into. This extensibility meant that as our needs evolved, our tooling evolved with us, seamlessly integrating into the cadence of how we actually build and deliver software.</p><p><br /></p><h3>Beyond code: Planning, design, and security 🎯</h3><p>But the transformation extended far beyond writing code. It reshaped how we plan software in the first place.</p><h4>AI-Powered software planning 📋</h4><p>We developed an agent capable of ingesting a product specification and decomposing it into a structured development roadmap. A complete  plan with clearly described user stories, dependencies mapped between them, estimated story sizes, and recommended technical approaches for each phase. What used to require hours of grooming sessions and whiteboard debates now emerged in minutes, giving us a foundation to refine rather than build from scratch. The agent didn't replace our judgment; it accelerated our ability to reach clarity.</p><h4>UI/UX Design to code pipeline 🎨</h4><p>Our product design workflow underwent a similar revolution. Moving from Figma sketches to functional code once meant painstaking translation. Designers handing off specs, developers interpreting margins and spacing, endless back-and-forth over pixel-perfect details. With our AI-boosted workflows, that gap collapsed. Designs became living prototypes in minutes, allowing us to iterate on real implementations rather than static mockups. The feedback loop between design and engineering tightened dramatically.</p><h4>The Solidity preliminary auditor🔒</h4><p>Perhaps one of the most impactful additions was our Solidity preliminary auditor.</p><p>In Ethereum development, security isn't a nice to have, it's existential 🔐. Traditionally, vulnerabilities were caught late in the cycle, often during expensive external audits. Our custom agent changed that calculus entirely. It analyzed smart contracts as we wrote them, flagging potential attack vectors, reentrancy risks, and gas inefficiencies before code ever left our local environment. Catching issues early didn't just save money; it shifted our entire security posture from reactive to proactive.</p><p><br /></p><h3>The coding models evolution of 2025 📈</h3><blockquote><p>If 2024 was the year AI learned to code, 2025 was the year it learned to think.</p></blockquote><p>The evolution of reasoning models throughout the year felt less like incremental updates and more like watching a new species of intelligence emerge in real-time.</p><p>Sonnet 4.0 set the tone early in the year, striking a remarkable balance between capability and efficiency. It became our workhorse, fast enough for real-time pair programming, sharp enough to handle the majority of our daily engineering tasks without breaking stride.</p><p>Then came GPT-5. OpenAI's flagship model arrived with capabilities that forced us to rethink our mental models. Its reasoning chains were longer, more coherent, and startlingly self-aware of their own limitations. It could plan multi-step implementations, anticipate where its own suggestions might fall short, and proactively flag areas requiring human oversight.</p><p>Sonnet 4.5 pushed the frontier further still. The leap in contextual understanding was palpable. It grasped nuance better, hallucinated less, and demonstrated an almost intuitive sense for codebases it had never seen before. Refactoring suggestions became more idiomatic. Architectural advice felt more grounded in real-world trade-offs.</p><p>And then <strong>Anthropic released Opus 4.5 </strong>⚡, the culmination of everything we'd seen throughout the year. This wasn't just a smarter model; it was a qualitatively different experience. Anthoropic Opus 4.5 could hold entire system architectures in its context, reason through sprawling dependency graphs, and execute complex refactors that previously demanded days of careful, manual work. We handed it to our old codebases like TAIKAI, our hackathon Platform with years of accumulated decisions, and it untangled them with surgical precision. Opus was able to help us circumvent cyber attacks and protect our platform with highly tailored security advice.</p><p><strong>In essence, a general IT engineer with full understanding of all engineering topics, augmenting the team's capabilities and decision power 💪.</strong></p><p><br /></p><h3>Looking ahead: what's next 🔮</h3><p>Looking back, the velocity of progress in 2025 was staggering. Each model release didn't just add features; it expanded what we believed was possible. Our workflows evolved in lockstep, constantly adapting to harness capabilities that, just months earlier, would have seemed like science fiction.</p><p>As we close out 2025, it's impossible to predict exactly where the next generation of coding models will take us. The pace of change has been so relentless that any forecast feels obsolete before it's written. But one thing is certain: whatever emerges next will only deepen our capabilities, allowing us to tackle challenges we haven't yet imagined with greater precision, speed, and confidence. The tools will grow sharper, the collaboration more seamless, and the boundaries of what a small team can achieve will continue to expand.</p><p><strong>We've gone from tentative experimentation to full embrace, from skeptics to believers. And if this year has taught us anything, it's that the sky truly is the limit.</strong></p><p><br /></p><h3>Key takeaways 💡</h3><ul><li><strong>Reasoning models changed the game: </strong>The shift from autocomplete to genuine reasoning transformed AI from a typing accelerator into an architectural thinking partner capable of handling complex engineering challenges.</li><li><strong>Guardrails are non-negotiable:</strong> AI velocity without governance leads to technical debt. Front-load planning, enforce review gates, and refactor deliberately, treat the AI as a thinking partner first, code generator second.</li><li><strong>Terminal-based agents sharpen focus:</strong> Stripping away IDE affordances forced clearer communication and produced more cohesive solutions. The constrained environment encouraged deeper reasoning rather than scattered suggestions.</li><li><strong>Extensibility unlocks real value: </strong>Custom subagents tailored to your workflows deployments such as our smart contract auditing subagent, multiply the benefits and evolve with your needs.</li><li><strong>Security can shift left: </strong>AI-powered preliminary auditors catch vulnerabilities during development, not after expensive external audits. For web3 development, this proactive security posture is existential, not optional.</li></ul><p><br /></p><p><em>This post is my own reflection on how we at <strong>LayerX</strong> evolved our engineering workflows throughout 2025, leveraging proprietary AI models from OpenAI and Anthropic and tools like Cursor. Next year, we're eager to explore smaller, open-weights models, more efficient alternatives to truly understand their potential on our workflows.</em></p><p><strong><em>Building in web3?</em></strong><em> I'd love to hear how AI tools are changing your workflow. Find me on <a href="https://x.com/heldervasc" target="_blank">X (Twitter)</a> or explore what we're building at <a href="https://layerx.xyz" target="_blank">LayerX</a>.</em></p>

From autocomplete to architectural partner, how reasoning models, terminal-based agents, and custom AI tooling transformed our engineering workflow at LayerX

The Agentic Shift: How AI Transformed LayerX Engineering Workflow

<p>Big changes are coming to the LayerX ecosystem, and they’re the kind of changes that simplify, strengthen, and set us up for the long game.</p><p>Today, we’re announcing that <strong>TKAI and BEPRO tokens will merge, coming together under a single new identity: $LX token.</strong></p><p>This isn’t “just another token launch.” </p><p>In fact, LX isn’t a new token minted from scratch: it’s the evolution of the current $BEPRO, which will gradually be renamed across exchanges, aggregators, price trackers, and the wider ecosystem.</p><p>On the TKAI side, holders will be able to swap their TKAI for BEPRO (future LX) at a fixed rate, making the transition smooth and predictable.</p><p>This merge brings everything under one unified brand: one token to represent the entire LayerX universe, not each product individually.</p><h3>Why Merge TKAI and BEPRO?</h3><p>LayerX has come a long way. What used to be separate products with separate identities is becoming a single, connected ecosystem. Our products range from hackathons, tasks, builder ecosystem, infrastructure tools, and more already in the pipeline. </p><p>So naturally, having two tokens made less and less sense. Having one token that reflects everything LayerX does makes a lot more.</p><p>This merge:</p><ul><li>Simplifies the ecosystem for users, builders, and partners</li><li>Brings all products under one shared economic layer</li><li>Gives more visibility and reach to the entire LayerX brand</li><li>Strengthens long-term token utility, instead of splitting it across two assets</li><li>Prepares the ground for new products coming into our portfolio</li></ul><p>LX is designed to become the token that represents our company, our mission, and the full value of the LayerX ecosystem, not a single platform or feature.</p><h3>What happens now?</h3><p>A quick overview of the transition:</p><p><strong>1. TKAI → BEPRO (future LX) Swap</strong></p><p>TKAI holders will be able to swap their TKAI for BEPRO at a fixed, fair price.</p><p><strong>2. $BEPRO → $LX Brand Migration</strong></p><p>Once the swap window opens, BEPRO will begin its gradual rebranding to LX across all platforms.</p><p>This process can take time. Exchanges, price trackers, wallets, and third-party services all update at different speeds. That’s normal.</p><p><strong>3. LX becomes the token of the entire LayerX ecosystem</strong></p><p>From products to governance to new launches, LX will be the backbone of the LayerX economy.</p><p>As we introduce more products and expand our portfolio, the token’s role will grow with it.</p><h3>A new chapter for LayerX</h3><p>We’re building something bigger than individual products.</p><p>We’re building a connected ecosystem. A platform for builders, creators, and communities to innovate at scale.</p><p>LX represents that evolution.</p><p>And yes… there’s a little fusion action involved because every great merge deserves a Super Saiyan moment.</p><p>More details, timelines, and instructions for TKAI holders will be released soon.</p><p>Welcome to the next era of LayerX.</p><p><strong><em>Welcome to LX.</em></strong></p>

Big changes are coming to the LayerX ecosystem, and they’re the kind of changes that simplify, strengthen, and set us up for the long game.

TKAI + BEPRO merge into $LX: The future of LayerX

How LayerX designed and developed BakerFi's complete DeFi vault platform, transforming complex yield strategies into a seamless user experience.(Use Case)

Inside BakerFi: Launching Secure DeFi Vault Platform

Inside BakerFi: Launching a Composable and Secure DeFi Vault Platform 🧑‍🍳

<p>A few months ago at the Base Meetup in Porto, Portugal 🇵🇹, I had the opportunity to connect with the <a href="https://bakerfi.ai" target="_blank">BakerFi</a> team in person and dive deep into their development journey. What struck me most wasn't just their innovative approach to Strategy Vaults, but the disciplined methodology that took them from initial concept to mainnet launch in just 120 days. In an industry where security breaches regularly make headlines and multi-million dollar exploits seem almost routine, their sprint challenged my assumptions about what's possible when building secure DeFi protocols at speed ⚡️</p><p>The conversation sparked an important question: Is it possible to move fast without breaking things in DeFi? The answer, as BakerFi demonstrated, is yes—but only with the right roadmap, unwavering commitment to security, and a deep respect for the complexity of blockchain development.</p><p>At <strong>LayerX</strong>, we've spent years building web3 infrastructure—from TAIKAI's token-based hackathon platform to Bepro Network's decentralized development orchestration. This experience has taught me that speed and security aren't mutually exclusive when you have the right processes in place. Let me share what I've learned about building secure DeFi protocols efficiently.</p><h3>The Reality of DeFi Development 🔍</h3><p>Before diving into the timeline, it's worth acknowledging the elephant in the room. The DeFi space has witnessed countless projects rush to market only to suffer catastrophic failures. From reentrancy attacks to flash loan exploits, oracle manipulations to economic design flaws, the graveyard of failed protocols serves as a sobering reminder that speed and security are often at odds ⚠️</p><p>Yet the BakerFi case study proves that this tension doesn't have to be fatal. In my experience building high-performance trading systems at Euronext—where a single bug could cost millions in microseconds—I learned that "moving fast" doesn't mean cutting corners. It means eliminating waste, building on proven foundations, and front-loading security considerations rather than treating them as a final checkbox. The same principles that kept financial infrastructure stable through billions of daily transactions apply equally to DeFi protocols.</p><h3>The 120-Day Roadmap 📋</h3><h4>Week 1-2: Smart Contract Architecture 📐</h4><p>The foundation of any successful DeFi protocol lies in its architectural decisions, and this is where most teams either set themselves up for success or future headaches. I've found that these critical first two weeks determine everything that follows.</p><p>Early on in protocol development, one of the most important architectural decisions you'll face is whether to design a monolithic contract or embrace modularity. In multiple projects, choosing a modular approach has saved countless hours during audits and upgrades. Core protocol design based on proven patterns isn't about lacking creativity—it's about standing on the shoulders of giants. I've studied battle-tested protocols like Aave, Compound, and Uniswap, understanding not just what they built, but why they made specific architectural choices. These patterns have survived millions of dollars in bug bounties and countless hours of security researcher scrutiny.</p><p>Modular architecture isn't just about clean code—it's about security. In my experience, when contracts are properly separated, each component can be tested in isolation, security audits become more manageable, and future upgrades don't require rewriting the entire system. Think of it like building with LEGO blocks rather than carving from a single piece of stone. When you need to update a specific part of the protocol (for example, a reward calculation logic), a modular design lets you swap out just that component without touching the core vault or governance contracts.</p><p>Clear separation of concerns creates natural security boundaries. For instance, vault logic must never mix with token logic, governance systems must operate independently of core protocol mechanics, and oracle integrations need proper abstraction. This separation makes it significantly harder for vulnerabilities to cascade across the system—a lesson reinforced by analyzing major DeFi exploits where one compromised component led to total protocol failure.</p><h4>Week 3-4: Development &amp; Unit Testing 🔧</h4><p>With architecture in place, development begins in earnest. But I've learned this isn't the cowboy coding phase—every line of smart contract code must be accompanied by comprehensive tests from day one.</p><p>Comprehensive unit test coverage aiming for 95%+ isn't arbitrary perfectionism. When I wrote "Asynchronous Android Programming," I emphasized that in environments where bugs are costly to fix post-deployment, testing isn't optional, it's survival. In DeFi, your code is immutable (or requires complex upgrade mechanisms), and bugs can cost millions. I've seen protocols lose their entire TVL because they didn't test a single edge case. Every function, every edge case, every conditional branch needs verification.</p><p>Edge case testing for all mathematical operations is particularly critical in DeFi. Having debugged C++ applications at Axway and Euronext, I learned that mathematical edge cases are where systems break. What happens when your protocol handles amounts near uint256.max? How does your liquidation logic behave when prices approach zero? At TAIKAI, we discovered our interest rate calculation broke down at extreme utilization rates—thankfully during testing, not on mainnet. These aren't hypothetical questions—they're real scenarios that will occur.</p><p>Gas optimization from day one isn't just about user experience—it's about security. In my experience optimizing high-performance systems, I've found that efficient code tends to be simpler code, and simpler code has fewer places for bugs to hide. Additionally, protocols that are expensive to interact with may see users batching operations or using aggregators in unexpected ways, potentially exposing vulnerabilities you didn't anticipate.</p><h4>Week 5-6: Integration &amp; Fork Testing 🍴</h4><p>This is where theory meets reality. I've learned that building a beautiful protocol on a local blockchain means nothing until you test it against real market conditions.</p><p>Mainnet fork testing has become one of my favorite tools. At LayerX, we run every protocol against exact snapshots of mainnet state before deployment. This means testing interactions with <strong>Aave's latest deployment, Uniswap's current liquidity pools, and Chainlink's actual price feeds</strong>. I've caught integration issues during fork testing that would have been catastrophic on mainnet—issues that simply can't be discovered in isolated environments.</p><p>Integration tests with actual protocols require scripting complex multi-step scenarios. One critical test we run: a user deposits collateral, borrows against it, and the vault mints shares—all within the same transaction. On the <strong>BakerFi </strong>project, we discovered our assumptions about transaction ordering broke down completely under adversarial conditions. These real-world scenarios are humbling but essential.</p><p>Stress testing with various market scenarios means simulating Black Thursday-style crashes, extreme volatility events, and prolonged periods of unusual market conditions. Here's a hard truth I learned: your protocol might work perfectly when ETH is stable at $2,000, but during a cascade of liquidations when it drops to $1,000 in an hour? That's when you discover what you really built. The trade-off is time—comprehensive stress testing takes weeks—but it's cheaper than a mainnet exploit.  </p><h4>Week 7-8: Fuzzing &amp; Advanced Testing 🎯</h4><p>At this stage, I'm looking for the bugs I don't know to look for. This is where advanced testing methodologies become crucial—and where I've found some of the most critical vulnerabilities.</p><p>Property-based testing (also known as invariant testing in the Ethereum ecosystem) involves defining properties that should always be true about your protocol and then having automated tools try to break those invariants. At TAIKAI, we defined invariants like "The sum of all user balances should always equal the total supply" and "A user's collateral value should always exceed their debt value unless they're liquidated." Simple statements, but incredibly powerful for catching subtle bugs.</p><p>Invariant testing tools like Echidna and Foundry's invariant testing run thousands of randomized transactions, trying every possible combination of function calls with random parameters. I've seen fuzzing campaigns discover vulnerabilities that survived extensive manual review and unit testing—bugs that would have cost us dearly on mainnet. The challenge? Setting up invariants correctly requires deep understanding of your protocol's intended behavior. Get them wrong, and you'll chase false positives for days.</p><p>Automated fuzzing campaigns running 24/7 throughout these weeks accumulate millions of test cases. I run these on dedicated servers at LayerX, letting them dig deeper into our protocol's state space with each passing hour. The longer they run, the more obscure edge cases they find. The trade-off is computational cost, but it's a small price compared to a protocol breach.</p><h4>Week 9-10: Private Security Audits 🛡️</h4><p>Now it's time to bring in external experts. I've learned that if you've followed the previous weeks diligently, you're not asking auditors to find your protocol's basic bugs—you're asking them to validate your security model and find the subtle vulnerabilities that even comprehensive testing might miss.</p><p>Multiple independent security firms provide defense in depth. At LayerX, we typically engage 1-2 firms for critical protocols. Each firm has different methodologies, different areas of expertise, and different tools. What one firm might miss, another might catch. The trade-off? Cost. Quality audits are expensive—expect $20K-200K per firm. But I've seen single vulnerabilities that would have cost millions if they made it to mainnet.</p><p>Both automated tools and manual review are essential. Automated tools like Slither, Mythril, and Securify can catch certain classes of vulnerabilities instantly. But the most dangerous bugs—the ones that lead to the biggest exploits—are often logical flaws that only human security researchers can identify. At TAIKAI, an auditor found a subtle economic exploit in our tokenomics that no automated tool would have caught. It required understanding game theory, not just code.</p><p>Private audit preparation involves creating comprehensive documentation, setting up dedicated environments for auditors, and establishing clear communication channels. I've learned to treat auditors as partners, not adversaries. The better your documentation, the deeper they can dig into the truly complex issues rather than asking basic questions about your design.</p><h4>Week 11-14: Competitive Audits &amp; Bug Bounties 🏆</h4><p>At this stage, the security review transitions from internal and private to a fully open and collaborative process—drawing on the expertise of the global security community. Hosting open, competitive audits is essential for achieving real-world resilience: the wider the net you cast, the more likely major vulnerabilities are to be discovered and resolved before launch.</p><p>It’s vital to involve multiple established platforms to maximize coverage and attract diverse security talent. Some of the main players in this space include:</p><ul><li><a href="https://code4rena.com/)" target="_blank">Code4rena</a></li><li><a href="https://cantina.xyz/" target="_blank">Cantina</a></li><li><a href="https://halborn.com/)" target="_blank">Halborn</a></li><li><a href="https://immunefi.com/" target="_blank">Immunefi</a></li></ul><blockquote><p>Checkout <a href="https://garden.taikai.network/partners?categories=%5B%27security%27%5D" target="_blank">TAIKAI's Garden Security Partners </a> section to get nice discounts.</p></blockquote><p>Running open competitions on these platforms exposes your protocol to thousands of security researchers who can each bring unique perspectives and attack methodologies. This crowd-sourced approach is not just about audit volume—it's about surfacing real risks from a multitude of angles to ensure that nothing critical is missed.</p><p>One of the most important steps after running these audits is the <strong>remediation period</strong>. During this time, the core development team works closely with both the auditing platforms and external researchers to address every vulnerability and recommendation that was surfaced. Every finding—large or small—should receive attention. This phase is a deep collaborative effort that involves triaging issues, prioritizing their fixes, and validating patches rigorously.</p><p>It’s essential to invest the time to polish and iterate on every issue found, ensuring that security is truly baked into the protocol before mainnet deployment. This cycle of open competition, remediation, and partnership with the security community leads to a protocol that is not only secure at launch, but has also earned trust through a transparent and collaborative review process.</p><h4>Week 15-16: Final Preparations 🎬</h4><p>The final sprint isn't just about deploying contracts—it's about preparing for life on mainnet. I've learned this phase is where operational excellence separates successful protocols from disasters waiting to happen.</p><p>Governance and emergency procedures mean having a plan for when things go wrong. Can you pause the protocol if a vulnerability is discovered? How quickly can you implement fixes? Who has the authority to trigger emergency actions, and how do you prevent those powers from being abused? At TAIKAI, we implemented a timelocked multisig with emergency pause capabilities. The trade-off? True decentralization versus security responsiveness. We chose a middle ground: emergency pause powers with transparent governance for permanent changes.</p><p>Community testing and feedback on testnets gives you a final chance to catch usability issues and identify potential attack vectors that even security experts might miss. Your community often includes talented developers who will probe your protocol in ways you didn't anticipate. At Bepro Network, community testing revealed a UX flow that could lead to user mistakes—not a security bug per se, but important enough to fix before mainnet.</p><h3>The Keys to Success 🔑</h3><p>The <strong>BakerFi</strong> approach demonstrates that 120 days is achievable, but only with the right mindset and methodology. Here's what I've learned from building multiple DeFi protocols:</p><p>Build on proven patterns instead of reinventing. 💡 Innovation is important, but every novel mechanism you introduce is a potential vulnerability. At TAIKAI, when we needed custom token mechanics, we extended proven OpenZeppelin or Solady contracts rather than building from scratch. Stand on the shoulders of giants whenever possible. Your innovation should be in the application layer, not in reinventing secure mathematical operations. </p><p><strong>Building around great foundations is the key for success.</strong></p><p>Prioritize security from day one, not as an afterthought. 🔒 Security isn't a phase of development—it's a mindset that permeates every decision. </p><p>Use comprehensive testing at every stage. ✅ Testing isn't something you do after development—it's something you do during development. I've found that writing tests before code (TDD) forces you to think through edge cases early. Let tests guide your design. This approach saved us countless hours of debugging.</p><p>Work with experienced audit teams early. 🤝 Don't wait until week 9 to contact auditors. I engage them during the architecture phase for preliminary review and maintain communication throughout development. Early auditor feedback has prevented costly architectural decisions that would have required major refactoring later.</p><h3>The Path Forward</h3><p>Building a secure DeFi protocol in 120 days isn't about rushing—it's about rigor. It's about having a clear roadmap, following proven patterns, and never compromising on security. The BakerFi case study shows us that when security is built into every step of the process rather than bolted on at the end, ambitious timelines become achievable.</p><p>The next generation of DeFi protocols will be built by teams that understand this balance. Teams that respect the complexity of blockchain development while refusing to let perfect be the enemy of good. Teams that move fast by moving deliberately.</p><h4><strong>Building Your DeFi Protocol?</strong></h4><p>If you're planning to launch a DeFi protocol and need guidance on security, architecture, or development strategy, we'd love to help. At LayerX, we specialize in building secure web3 dapps and can support your team.</p><p>Connect with me:</p><ul><li>Follow me on X: <a href="https://x.com/heldervasc" target="_blank">@heldervasc </a>for more insights on DeFi development, web3 security, and distributed systems</li><li>Check out our work: <a href="https://layerx.xyz" target="_blank">LayerX</a> | <a href="https://taikai.network" target="_blank">TAIKAI</a></li><li>Reach out if you need help launching your protocol securely</li></ul><p>The DeFi space needs more teams building with security and rigor. Let's make it happen together.</p><p><em>Have experience with DeFi protocol development? I'd love to hear what worked (and what didn't) for your team. The best insights come from shared learning.</em></p>

A battle-tested roadmap for launching secure DeFi protocols in 120 days, based on real experience building web3 infrastructure at LayerX and TAIKAI

How to launch a Secure DeFi Protocol in 120 Days 🚀

<p>Remote work, salary expectations, motivation, appreciation, and feedback were already some of the challenges that, as a professional in the field, I faced in any business context, and then I had to add Web3 to the equation. I have explained what Web3 is in various ways, and I will now replicate the explanation that I considered most suitable for my level of understanding, which was (perhaps still is) quite limited. </p><p><br /></p><h3>From Web1 to Web3</h3><p>To explain what Web3 is, I'll start by explaining what Web1 is, followed by Web2 (don't give up just yet, I want to remind you that I am a psychologist, and I managed to grasp this evolution). Web1 (World Wide Web) is the first phase of the internet, which emerged in the 1990s, and it allowed us to read content, meaning it is considered a medium for distributing static information (no user interaction). A good example of Web1 is a news website, which is unilaterally fed, and the user only consumes its content.</p><p>In the early 2000s, Web2 emerged with a significant innovation: user interaction. Users, in addition to consuming content, could now write and share information/content with other users, giving rise to platforms like blogs and social media sites such as Facebook, Twitter, and Instagram, for example.</p><p>Currently, there is much talk about Web3, but what is the main evolution of this new web? This third generation of the internet allows us to be owners of our own content, enabling us to monetize it without relying on intermediaries (e.g., Youtube, Spotify, Instagram). And how do we ensure all this? </p><p>Through Blockchain technology! </p><p><br /></p><h3>Blockchain enters the scene</h3><p>Another new term! What is Blockchain? Once again, I'll explain it in the simplest way, perhaps the only way I know how. Before Web3, all information was stored in closed databases controlled by their owners (e.g., Google, Facebook), giving them the ability to alter and manipulate this information, as well as use personal data for less ethical campaigns (who remembers the Cambridge Analytica scandal?). </p><p>The Blockchain came to change this paradigm through its structure of blocks, where each block contains a set of transactions, and every user in the network has a copy of the content of all blocks since the network's genesis. This guarantees information transparency and, consequently, data security. This is because, for these records to be altered by third parties, they would need to be changed simultaneously in all existing copies of the distributed ledger (a very complex and practically impossible task).</p><p><br /></p><p>Now you might ask: What does this have to do with the Human Resources Department? Everything and nothing at the same time...</p><p>Directly, it doesn't have any impact because our direct interaction is with the employees of our team, but these employees work in very specific areas directly connected to this world (developers, business developers, designers, marketers). So, what exactly changes? A lot of things.</p><p>In this article, I chose to focus on the recruitment process, as it is the first People process to be executed.</p><p><br /></p><h3>Recruitment</h3><p>This process, besides being, in my opinion, one of the most important processes, now becomes the most challenging and complex. In addition to the common challenges - high salary expectations, experience in the role, soft skills aligned with the culture and position, candidate motivation, among others - we now have a series of new challenges related to:</p><p><br /></p><h4>Candidates with Web3 experience</h4><p>Obviously, to enter this Web3 world, at some point, you will have to gain experience (as was my case), but many of the needs have to be fulfilled quickly, which means - ASAP. So, what would simplify things significantly? Finding someone with experience in the field. However, the area is relatively new, and there are only a few companies, so how can we guess who has experience? Since these companies are emerging and acting within a community, they end up helping each other, so it is not ethically well-regarded to "steal" employees from other companies.</p><p><br /></p><h4>Higher salaries than the ones we already know</h4><p>Typically, a course in computer science/programming/engineering is heavily focused on Web2 because it is the most common and, therefore, considered the "safer" path. This means that candidates who want to enter the Web3 ecosystem often need to be self-taught. This proactive approach from these professionals requires time and dedication, and when seeking a challenge, they expect this extra effort to be proportionately rewarded. However, this world is also new for Web3 companies themselves, and although we believe that growth is assured, the available capital for most companies is still quite limited.</p><p><br /></p><h4>Recruitment channels in the Web3 space</h4><p>It has been very challenging to focus the active capital research on a single platform. Until now, I used LinkedIn for all positions. However, with the increase in comprehensive recruitment platforms for Web3, this relatively small group of professionals, where, according to <a href="https://github.com/electric-capital/crypto-ecosystems" target="_blank">Github and Electric Capital</a>, the market has around 50,000 developers within or interested in entering this world, may face difficulties in figuring out where to be active in their search for challenges. On the other hand, companies are beginning to invest more money in posting vacancies on each of the existing sites to access a small percentage of these professionals.</p><p><br /></p><p>These are three of the major challenges I have encountered. Now, let’s go over how you can manage these challenges.</p><p><br /></p><h4>Candidates with Web3 experience</h4><p>In this first point, as I mentioned earlier, the difficulty lies in finding candidates with experience while also maintaining collaboration with other companies as a basis. For this reason, I oscillate between having an inbound and an outbound strategy. Inbound, because we post job openings and hope that candidates proactively express their interest in collaborating with us. However, this often doesn't yield a large volume of applications since these professionals are approached daily by many other companies and may not feel the need to actively search for opportunities. On the other hand, I have an outbound strategy because, thanks to our community, which is constantly engaged and nurtured by our team to foster growth, sharing, and information exchange, we can find many knowledgeable professionals who meet our needs and are familiar with LayerX's culture, vision, and mission.</p><p><br /></p><h4>Higher salaries than what we are already familiar with</h4><p>It would be very gratifying to say that we can meet or exceed the expectations of one-third of the candidates, as that would allow us to respond to the team 300% faster and reduce the recruitment time to 3 weeks. How wonderful that would be! Unfortunately, this is not our reality, nor is it for much of the industry, which is still in the phase of growth and market exploration. So, how do I address this situation? In the first contact with the candidate, I try to convey our company culture, meaning during the interview, my approach is exactly what we experience on a daily basis – relaxed and somewhat cheerful. I am not a proponent of awkward, impersonal interviews that attempt to establish a power dynamic because I believe it only drives candidates away. It is essential to remember that the premise of the company solely choosing the candidate is not applicable in today's world. After this initial contact, we present our range of both conventional and unconventional benefits in subsequent interactions.</p><p><br /></p><h4>Recruitment channels for the Web3 world</h4><p>I cannot give you a single solution because that is exactly the problem I face. However, I can share three recruitment platforms for Web3 that I have had the opportunity to explore more in-depth over the past year and a half. </p><p>The first is <a href="https://wellfound.com/" target="_blank">Wellfound</a> (formerly known as AngelList), where we can find a considerable volume of candidates compared to others, but we believe they tend to be more junior profiles with limited experience in the field, which hasn't been very helpful for us. </p><p>The second platform is <a href="https://rviewer.io/" target="_blank">Rviewer</a>, another technological recruitment platform that charges an 8% commission on the candidate's annual gross salary after they are hired. The third platform is <a href="https://cryptojobslist.com/" target="_blank">CryptoJobList</a>, which I haven't had the chance to work with personally, but I have exchanged impressions with people in the field who use it. It operates similarly to LinkedIn, where the company chooses the budget it wants to allocate to a position, and the more we pay, the more visibility we get.</p><p>Finally, we always maintain our website because our Marketing team has done an excellent job promoting LayerX, which has positively impacted the number of applications we receive through the site.</p><p><br /></p><h3>In summary</h3><p>This new era of the internet is not only a challenge for professionals in technological roles but also for all areas across a company. The group of people dealing with these challenges is quite extensive. </p><p>However, I believe that the attitude of collaboration, empathy, and solidarity adopted to face them has been fundamental for healthy and solid growth in such a still nascent market with enormous growth potential. This is precisely the ethos of Web3 and decentralization – growing together and stronger, adapting to the challenges posed by the market.</p><p>I truly believe we are on an excellent path, and the opportunities that will arise are boundless. So, if you share the same belief, I am fully available to assist you on this journey.</p><p><br /></p><h4><em>Did you enjoy what you read?</em></h4><p><em>Follow me on <a href="https://www.linkedin.com/in/elisabetemoura/" target="_blank">LinkedIn</a> and share your opinions and feedback with me, and with your friends if you think this content is relevant to them.</em></p>

<p id="isPasted">Trabalho remoto, expectativas salariais, motiva&ccedil;&atilde;o, reconhecimento e feedback j&aacute; eram alguns dos desafios com que, como profissional da &aacute;rea, me deparava em qualquer contexto empresarial, sendo que &ldquo;s&oacute;&rdquo; tive que somar Web3 &agrave; equa&ccedil;&atilde;o.</p><p>Explicaram-me o que &eacute; Web3 de v&aacute;rias formas e eu vou replicar a explica&ccedil;&atilde;o que considerei mais ajustada ao meu n&iacute;vel de sabedoria que era at&eacute; ent&atilde;o (talvez ainda seja) bastante limitada. Antes de come&ccedil;ar pela Web3, come&ccedil;o por explicar o que &eacute; Web1, seguida da Web2 (n&atilde;o desistam j&aacute;, relembro que sou psic&oacute;loga e consegui entender esta evolu&ccedil;&atilde;o).&nbsp;</p><p>A Web1 (World Wide Web) &eacute; a primeira fase da internet. Surgiu na d&eacute;cada de 1990 e &eacute; aquela que nos permitia ler conte&uacute;do, por isso , era considerada um meio de distribui&ccedil;&atilde;o de informa&ccedil;&atilde;o est&aacute;tica (n&atilde;o existia intera&ccedil;&atilde;o com os usu&aacute;rios). Um bom exemplo da Web1 &eacute; um site de not&iacute;cias, que &eacute; alimentado unilateralmente, onde o utilizador apenas consome o seu conte&uacute;do.</p><p>No in&iacute;cio de 2000, surge a Web2, com a grande novidade da intera&ccedil;&atilde;o, onde os utilizadores al&eacute;m de consumir o conte&uacute;do, j&aacute; podiam escrever e partilhar informa&ccedil;&otilde;es/conte&uacute;do com outros utilizadores, surgindo nesta altura os Blogs e redes sociais como Facebook, Twitter e Instagram, por exemplo.&nbsp;</p><p>Atualmente, j&aacute; se fala muito em Web3, mas qual &eacute; a principal evolu&ccedil;&atilde;o desta nova web? Esta terceira gera&ccedil;&atilde;o da internet permite sermos propriet&aacute;rios do nosso pr&oacute;prio conte&uacute;do, podendo monetiz&aacute;-lo sem recorrer a intermedi&aacute;rios (e.g. Youtube, Spotify, Instagram). E como &eacute; que garantimos tudo isso?</p><p><br></p><p>Atrav&eacute;s da tecnologia Blockchain!</p><p>Outra palavra nova! O que &eacute; a Blockchain? Mais uma vez, explico da maneira mais simples, para n&atilde;o dizer a &uacute;nica maneira que sei explicar. Antes da Web3, todas as informa&ccedil;&otilde;es eram armazenadas em bases de dados fechadas, apenas controladas pelos seus propriet&aacute;rios (e.g. Google, Facebook) que, por sua vez, tinham a possibilidade de proceder &agrave; altera&ccedil;&atilde;o e manipula&ccedil;&atilde;o dessas informa&ccedil;&otilde;es, bem como &agrave; utiliza&ccedil;&atilde;o de dados pessoais para campanhas menos l&iacute;citas (quem se lembra do esc&acirc;ndalo do <a href="https://pt.wikipedia.org/wiki/Cambridge_Analytica" rel="noopener noreferrer" target="_blank">Cambridge Analytica</a>?).</p><p>A Blockchain veio alterar este paradigma atrav&eacute;s da sua estrutura em blocos, onde cada bloco cont&eacute;m um conjunto de transa&ccedil;&otilde;es e onde cada utilizador dessa rede possui uma c&oacute;pia do conte&uacute;do de todos os blocos desde a cria&ccedil;&atilde;o da rede, o que garante a transpar&ecirc;ncia da informa&ccedil;&atilde;o e por sua vez a seguran&ccedil;a dos dados. Isto porque, para que estes sejam alterados por terceiros teriam de ser alterados ao mesmo tempo em todas as c&oacute;pias existentes do registo distribu&iacute;do (muito complexo e praticamente imposs&iacute;vel de acontecer).</p><p><br></p><p id="isPasted">Agora perguntam: E o que &eacute; que isso tem a ver com o Departamento de Pessoas? Tudo e nada ao mesmo tempo&hellip;&nbsp;</p><p>Diretamente n&atilde;o tem qualquer impacto porque a nossa intera&ccedil;&atilde;o direta &eacute; com os colaboradores da nossa equipa, mas esses colaboradores trabalham em &aacute;reas muito espec&iacute;ficas e diretamente ligadas a este mundo (developers, business developers, designers, marketeers). Ent&atilde;o, afinal o que &eacute; que muda? Muita coisa. &nbsp;</p><p>No presente artigo, optei por me centrar no processo de recrutamento, uma vez que este &eacute; o primeiro processo de Pessoas People a ser executado.&nbsp;</p><p><br></p><h3>Recrutamento</h3><p>Este processo, al&eacute;m de ser, na minha opini&atilde;o, um dos processos mais importantes, torna-se agora o mais desafiante e complexo. Al&eacute;m dos desafios comuns - expectativas salariais elevadas, experi&ecirc;ncia na fun&ccedil;&atilde;o, soft skills alinhadas com a cultura e posi&ccedil;&atilde;o, motiva&ccedil;&atilde;o do candidato, entre outros - temos agora uma s&eacute;rie de novos desafios que passam por:</p><h4>Candidatos com experi&ecirc;ncia em Web3</h4><p>Obviamente, para entrar neste mundo Web3, em algum momento, ter&aacute;s de entrar &agrave; experi&ecirc;ncia (como foi o meu caso), mas grande parte das necessidades tem de ser colmatadas r&aacute;pido, o que significa - para ontem. Por isso, o que &eacute; que simplificaria muito? Encontrar algu&eacute;m com experi&ecirc;ncia na &aacute;rea. Mas a &aacute;rea &eacute; recente e as empresas s&atilde;o poucas e querem adivinhar? Como est&atilde;o a nascer agora, e atuam em comunidade acabam por se ajudar mutuamente, por isso, eticamente, n&atilde;o &eacute; bem visto &ldquo;roubar&rdquo; colaboradores a outras empresas.&nbsp;</p><p><br></p><p><strong>Sal&aacute;rios mais elevados do que os elevados que j&aacute; conhecemos</strong></p><p>Tipicamente, um curso de inform&aacute;tica/programa&ccedil;&atilde;o/engenharia est&aacute; muito virado para Web2, porque &eacute; o mais comum e por isso o caminho mais &ldquo;seguro&rdquo;, o que representa um trabalho autodidata para os candidatos que querem entrar no ecossistema Web3. Esta proatividade requer tempo e dedica&ccedil;&atilde;o por parte destes profissionais e, por isso, na hora de procurar um desafio profissional eles esperam que esse esfor&ccedil;o extra seja retribu&iacute;do proporcionalmente. No entanto, este mundo tamb&eacute;m &eacute; novo para as pr&oacute;prias empresas de Web3 e embora seja um crescimento que acreditamos ser garantido, o capital dispon&iacute;vel para a maioria das empresas ainda &eacute; muito limitado.&nbsp;</p><p><br></p><h4>Os meios de recrutamento para o mundo Web3</h4><p>Tem sido muito dif&iacute;cil centrar a pesquisa ativa de capital numa s&oacute; plataforma &ndash; at&eacute; ao momento, eu usava apenas o <a href="https://www.linkedin.com/feed/" rel="noopener noreferrer" target="_blank">Linkedin</a> para todas as posi&ccedil;&otilde;es. No entanto, com o aumento de plataformas de recrutamento para Web3 bastante completas, este grupo de profissionais relativamente reduzido, que de acordo com a <a href="https://github.com/electric-capital/crypto-ecosystems" rel="noopener noreferrer" target="_blank">Github and Electric Capital</a> conta com cerca de 50 mil developers activos ou com interesse em entrar neste mundo, poder&aacute; apresentar dificuldades em perceber onde dever&aacute; estar ativo na sua procura por desafios. Por outro lado, as empresas come&ccedil;am a ter de investir mais dinheiro na abertura de vagas em cada um dos sites existentes para poder aceder a uma pequena percentagem desses profissionais.&nbsp;</p><p><br></p><p>Estes s&atilde;o tr&ecirc;s dos grandes desafios com que me tenho deparado. Por outra parte, gostaria de partilhar de que maneira &eacute; que tenho gerido estes desafios.</p><p><br></p><h4>Candidatos com experi&ecirc;ncia Web3</h4><p>Neste primeiro ponto, como referi anteriormente, a dificuldade &eacute; encontrar candidatos com experi&ecirc;ncia e ao mesmo tempo manter como base a colabora&ccedil;&atilde;o com outras empresas. Por essa raz&atilde;o, oscilo entre ter uma estrat&eacute;gia inbound e outbound. Inbound, porque publicamos as vagas e esperamos que os pr&oacute;prios candidatos de forma proativa apresentem o seu interesse em colaborar connosco, o que, muitas vezes, n&atilde;o nos permite aceder a um grande volume de candidaturas, j&aacute; que estes profissionais s&atilde;o abordados diariamente por uma s&eacute;rie de empresas e, talvez por isso, n&atilde;o sintam a necessidade de procura. Por outro lado, tenho uma estrat&eacute;gia outbound, porque gra&ccedil;as &agrave; nossa comunidade, que &eacute; diariamente acompanhada pela nossa equipa, visando assim o seu crescimento, partilha e trocas de informa&ccedil;&atilde;o &eacute; poss&iacute;vel encontrar muitos profissionais dotados de conhecimento que cobrem as nossas necessidades e ainda, que conhecem a <a href="https://layerx.xyz/" rel="noopener noreferrer" target="_blank">LayerX</a> (cultura, vis&atilde;o e miss&atilde;o).&nbsp;</p><p><br></p><h4>Sal&aacute;rios mais elevados do que os elevados que j&aacute; conhecemos</h4><p>Seria bom poder dizer que conseguimos acompanhar ou ultrapassar as expectativas de ⅓ dos candidatos, uma vez que isso significaria conseguir dar respostas 300% mais r&aacute;pidas &agrave; equipa e reduzir o tempo de recrutamento para 3 semanas. Que bom seria! Infelizmente n&atilde;o &eacute; a nossa realidade, nem de grande parte do setor que ainda est&aacute; em fase de crescimento e explora&ccedil;&atilde;o do mercado, &nbsp;por isso como contorno a situa&ccedil;&atilde;o?</p><p>Num primeiro contacto com o candidato, tento transmitir a nossa cultura empresarial, quero dizer, durante a entrevista a postura que tenho &eacute; exatamente aquela que vivenciamos no dia a dia, descontra&iacute;da e de alguma forma, animada. N&atilde;o sou nada a favor de entrevistas constrangedoras, impessoais e que tentam marcar um n&iacute;vel de poder, porque a&iacute;, acredito que s&oacute; conseguirei afastar os candidatos e &eacute; importante relembrar que a premissa de que &eacute; s&oacute; a empresa que escolhe o candidato n&atilde;o &eacute; aplic&aacute;vel nos dias de hoje. Depois desse primeiro contacto, s&atilde;o apresentados nos contatos posteriores o nosso leque de benef&iacute;cios convencionais e n&atilde;o convencionais.</p><p><br></p><h4>Os meios de recrutamento para o mundo Web3</h4><p>N&atilde;o vos poderei dar um &uacute;nico meio porque esse &eacute; exatamente o problema com que me deparo, mas posso partilhar, antes de mais, tr&ecirc;s plataformas de recrutamento para Web3 que tive a oportunidade de conhecer de forma mais aprofundada ao longo deste ano e meio: a <a href="https://wellfound.com/" rel="noopener noreferrer" target="_blank">Wellfound</a> (antiga AngelList), onde podemos encontrar um volume consider&aacute;vel de candidatos comparando com as outras &ndash; ainda assim, acreditamos que sejam perfis mais juniores e com pouca experi&ecirc;ncia na &aacute;rea, o que n&atilde;o nos tem ajudado muito; a <a href="https://rviewer.io/" rel="noopener noreferrer" target="_blank">Rviewer</a> &eacute; uma outra plataforma de recrutamento tecnol&oacute;gico e apresenta uma taxa de 8% de comiss&atilde;o sobre o sal&aacute;rio bruto anual do candidato, ap&oacute;s a sua contrata&ccedil;&atilde;o; com a <a href="https://cryptojobslist.com/" rel="noopener noreferrer" target="_blank">CryptoJobList</a> nunca tive a oportunidade de trabalhar, mas j&aacute; troquei v&aacute;rias impress&otilde;es com pessoas da &aacute;rea que utilizam &ndash; funciona como o Linkedin, no sentido em que a empresa escolhe o budget que quer destinar a essa posi&ccedil;&atilde;o (quanto mais pagamos, mais destaque temos). Por &uacute;ltimo, alimentamos sempre a nossa p&aacute;gina web, porque, paralelamente, a nossa equipa de Marketing tem feito um excelente trabalho na divulga&ccedil;&atilde;o da LayerX, o que impactou de forma positiva nas candidaturas atrav&eacute;s do site.&nbsp;</p><p><br></p><p id="isPasted">Em suma, esta nova era da internet n&atilde;o &eacute; apenas um desafio para os profissionais com fun&ccedil;&otilde;es tecnol&oacute;gicas, mas tamb&eacute;m para todas as &aacute;reas transversais a uma empresa. O universo de pessoas que est&aacute; a lidar com estes desafios &eacute; bastante alargado e acredito que a atitude que est&aacute; a ser adoptada para encar&aacute;-los &ndash; de colabora&ccedil;&atilde;o, empatia e solidariedade &ndash; tem sido fundamental para o seu crescimento saud&aacute;vel e s&oacute;lido num mercado t&atilde;o ainda embrion&aacute;rio mas com um potencial de crescimento enorme. &Eacute; precisamente este o ethos da Web3 e da descentraliza&ccedil;&atilde;o: crescermos em conjunto e mais fortes, adaptando-nos aos desafios que o mercado nos vai colocando.</p><p>Acredito verdadeiramente que estamos num excelente caminho e que as oportunidades que se v&atilde;o abrir ser&atilde;o infind&aacute;veis, por isso se acreditas no mesmo que eu, estou inteiramente dispon&iacute;vel para te ajudar nessa jornada.</p><p><br></p><h4 id="isPasted">Gostaste do que leste?</h4><p>Segue-me atrav&eacute;s do meu perfil de <a href="https://www.linkedin.com/in/elisabetemoura/" rel="noopener noreferrer" target="_blank">Linkedin</a> e partilha comigo as tuas opini&otilde;es e feedback e com os teus amigos se achares que este conte&uacute;do &eacute; relevante para eles.</p>

Remote work, salary expectations, motivation, appreciation, and feedback. My thoughts on web3 hiring.

Trabalho remoto, expectativas salariais, motivação, reconhecimento e feedback. A minha opinião sobre recrutamento na web3

LayerX: The team that makes AI work inside your business