Tech Lead / Engineering Lead (Contractor)

This is a Tech Lead position slightly different from the ones we usually post here.

We are looking for the first person to technically lead our first proprietary product. That's why we took special care to explain the context, the challenges, the responsibilities, and what we expect from this role.

Below you will find a more complete description than usual. The intention is that, even before applying, you can fully understand the challenge we are proposing and evaluate whether it makes sense for you.

The Challenge:

This is Lab Secreto's first proprietary product — built with intensive use of AI agents and an execution pace outside the market standard, under the direct leadership of the Lab's CEO. Now it's time to bring someone on board to take technical ownership and build the team that will carry this forward.

If you read this and think "this is the kind of challenge I want to take on," keep reading — the rest of this job posting was written for you to decide based on real information, not to look pretty.

The Challenge:

You will lead the product and its team, in direct partnership with the CEO and CTO. In practice, this means:

• Solid software architecture fundamentals, a maker mindset, and the ability to execute quickly and precisely using AI.
• Be the technical owner of the product. Architecture, contracts, standards, quality. Structural decisions come from conversations between you and leadership; the defense and execution are yours.
• Translate business vision into an executable sequence, in order, scope, and delivery.
• Write code and sustain velocity.
• Build and lead the product team. Define the profile, participate in hiring, and set the technical standard that others will follow.
• Establish how work is validated here. How do we know what was produced is correct? This question is yours to answer and implement.

What we need you to already have:

1. Solid software architecture fundamentals — non-negotiable. You must be able to speak with authority about:

• Real domain modeling. Distinguishing instance types, stable identity from temporary identifiers, event state signal ownership.
• Contract versus implementation. Defining what exists without leaking how it works.
• Distributed systems in practice. Idempotency, reliable delivery, reconciliation, compensation, ordering. Knowing that a successful call does not prove the operation finished.
• Real-time data. Initial state plus incremental updates, loss detection, resynchronization, backpressure, latency.
• Versioning and compatibility. Evolving contracts without breaking consumers.
• Knowing when not to abstract. Generalizing too early, splitting services too soon, and turning every piece of data into an object are mistakes that cost dearly.

2. Regarding tech stack: it matters far less than how you think. We currently work mainly with TypeScript/Node and C#/Unity, but the list of languages on your resume is not the criterion — your willingness to learn whatever the problem demands, yes.

3. Industrial, geospatial, telemetry, 3D, or video domain experience is welcome, but none of it is a blocker — we teach it here, including taking you into the field. Fundamentals, however, are non-negotiable.

4. Pace: The pace standard for this role is the same we apply to other Lab initiatives: fast delivery, short cycles, and intensive use of AI agents from day one. We say this because it is the real velocity expectation for the role. Our biggest challenge is finding someone who can sustain a pace of executing quickly and precisely. Velocity that generates rework is not velocity.

5. Execution with AI (and here a distinction is important) — We use AI massively. Not as an accessory: it is the mode of production. Today's work is not writing lines of code, but building the loops and tools that validate what agents produce, reviewing plans before execution, and interrogating results — by asking questions, not reading line by line. Agents are not autonomous here; they operate within a verification system that someone had to design. This is the opposite of vibe coding. Vibe coding is accepting output because it seems to work. What we do requires stronger fundamentals, not weaker ones: to specify well, to design verification, to recognize wrong abstractions in a plan before they become code, and to know which question exposes the problem.

If you read this description and think "this is laziness" or "this is a toy," it won't work. If you read it and think "this is how I want to work, but I don't yet know how to do it properly" — great, let's talk. The method is taught during the process. What cannot be trained in a timely manner are the fundamentals.

Our engineering philosophy: output is not outcome

This part of the description was written with great care. We want you to understand how we think about engineering, product, and delivery — and to assess whether this way of working makes sense for you. Therefore, we recommend reading this section carefully before proceeding to the rest of the description.

Delivering is not solving. Code written, service deployed, and sprint closed are output. Outcome is the business result — ours and our clients'. Only the second column counts.

That's why we don't fall in love with frameworks, perfect over-engineered architectures, a constellation of microservices, or the tooling needed to manage the complexity we created ourselves. Self-inflicted complexity is the most expensive way to appear sophisticated.

We believe in emergent architecture and many short iteration cycles. The right structure emerges from the real problem, under usage pressure — not from a document written before any contact with reality. Each cycle paves a safe and validated path for the client.

None of this is a license to do sloppy work. What we build must be robust and up to the task we set out to solve. A practical consequence: we don't look for people whose professional identity is tied to a specific language or stack. Tool choice here is always subordinate to the result and changes when it needs to. We look for engineers and software architects willing to execute, not to admire their own creations.

Note that this does not contradict the requirement for strong fundamentals from the previous section. It is exactly the opposite: only those who master fundamentals can safely decide what not to build. Over-engineering is usually insecurity disguised as rigor.

About the partnership

You will work directly with our CEO, who also leads the product. He is creative, hands-on, fast, and bold. He has a strong and detailed product vision, generates many ideas, and bets big. He prototypes instead of discussing for too long. He changes direction when evidence appears and expects the duo to navigate ambiguity rather than waiting for it to resolve itself.

This is great for those who like to build and can be uncomfortable for those who need more stable ground. Both reactions are legitimate — it's just better to discover which one is yours beforehand, not afterward.

What we expect from whoever takes this position:

• Translate direction into order. Many things will happen at once. Someone needs to turn this into sequence, priorities, and clear decisions.
• Maintain pace without losing precision. Fast and right. Not fast and then redo.
• Disagree when necessary. If a technical decision doesn't make sense, poses a significant risk, or a product choice compromises the solution, this needs to be said immediately — not three sprints later. Automatic agreement is the worst possible outcome here.
• Be the technical owner. Decisions made jointly become the responsibility of whoever assumes technical leadership: to defend, execute, and, when necessary, revise.
• Perhaps this is not a good role for you if: you prefer working from closed requirements, need established processes to function well, understand velocity and quality as necessarily opposing forces, or measure your work primarily by the elegance of the solution rather than the result it produces.

About the product

It is an operational intelligence platform focused on industrial environments: it connects corporate, geographical, historical, and real-time data, contextualizes everything in a common operational model, and supports decision-making and execution in a governed and auditable manner.

The first use case is focused on port operations, but the pattern applies to other industrial environments — mining, logistics yards, industrial plants, energy, and railways.

Who we are

Lab Secreto is a Brazilian strategic consultancy positioned as an alternative to traditional firms — practical results and technology as a transformation tool for heavy industry. We operate in three areas: .TECH (generative and applied AI, data, digital twins, complex systems, custom hardware, XR), .EXCELLENCE (Lean & Six Sigma, operational efficiency, productivity, and ROI), and .ESG.

Conditions

• B2B Contractor Model (PJ)
• Equity — in the product or the Lab. We are willing to offer equity for this position and want to discuss this openly during the process.
• Flexible benefits via card (Caju) and SulAmérica health plan (optional) — details in the offer.
• Retention bonus equivalent to one invoice upon completing 12 months.
• Paid PTO each contract year — detailed conditions in the process.
• Flexible format. We have an office in Downtown Rio, and there will be periodic visits to field operations.