Founding Backend Engineer — Product Infrastructure & Data

Location: Remote; North American time-zone overlap preferred
Commitment: Part-time, approximately 8–15 hours per week
Compensation: Equity-only, anticipated range 1%–3%
Apply: Through Wellfound

About Palette

Palette turns travel content people discover online into organized places, maps, and shareable trips.

Instead of losing a restaurant, hotel, activity, or destination inside TikTok, Instagram, YouTube, a notes app, or a group chat, people can save it to Palette. Our system turns that content into structured travel cards, matches it to real-world locations, displays it on a map, and helps users build and share itineraries.

We are an early, remote team working across product, design, and engineering. Palette has a working product and an existing backend. We now need a founding backend engineer to take long-term ownership of the systems that make capture, organization, sharing, collaboration, and trustworthy travel-intent data possible.

The role

This is a hands-on founding-team role—not a fixed-scope consulting project, an AI research position, or a job focused primarily on installing analytics tools.

You will inherit a working TypeScript, Node.js, Express, and MongoDB backend. Your job is to understand it before replacing it, identify the highest-risk architectural gaps, and improve it incrementally while the product continues to develop.

You will work directly with the founders, frontend engineering, and design. You will help translate changing product requirements into durable backend decisions, communicate technical trade-offs in plain language, and establish the foundation that future backend contributors will inherit.

The right person enjoys both architecture and the unglamorous work required to keep a real system dependable: debugging, migrations, retries, monitoring, tests, documentation, and production support.

What you will own

Product data architecture

• Redesign how canonical place and content data relate to user-saved cards, trip-specific card instances, notes, dates, ordering, creator commentary, and group context.
• Solve the current Master Card propagation problem so itinerary-specific changes do not overwrite a user’s original saved inspiration.
• Design schemas and migration paths that support ShareLinks, copied trips, group planning, and future creator experiences.
• Balance data integrity, development speed, and query performance without introducing unnecessary complexity.

Capture and processing reliability

• Own the pipeline that receives social and web content and turns it into structured travel cards.
• Improve input validation, duplicate prevention, idempotency, retries, partial-failure recovery, and error visibility.
• Introduce background jobs or queues where they solve a real reliability or performance problem.
• Improve structured metadata extraction, multi-location handling, language support, and location resolution.
• Build graceful fallbacks when external platforms, AI providers, or place APIs fail or change.

Product infrastructure and security

• Design and maintain APIs, authentication, authorization, and access controls.
• Support secure ShareLink permissions such as public read-only access, copying, commenting, collaboration, and access requests.
• Improve database indexes, connection handling, migrations, rate limiting, caching, and third-party API integrations.
• Establish practical logging, monitoring, alerting, and production-debugging workflows.
• Keep the system understandable and maintainable for a small, distributed team.

Trustworthy behavioral data

• Help define a reliable event model covering the journey from saving content to creating, sharing, importing, and eventually booking a trip.
• Decide which events should be recorded by the browser versus the backend.
• Maintain consistent identifiers across users, cards, trips, ShareLinks, and external sources.
• Prevent duplicate or misleading events caused by retries, anonymous sessions, failed jobs, or inconsistent naming.
• Start with a lean analytics setup and recommend more infrastructure only when product needs and usage justify it.

What the first 60 days could look like

The exact plan will be shaped together after reviewing the current system.

First 30 days

• Learn the product, users, current architecture, and social-content capture flow.
• Audit the Node.js, Express, and MongoDB backend for reliability, security, schema, testing, and observability risks.
• Document how data currently moves from an incoming link to a saved travel card and itinerary.
• Identify the highest-risk technical issues and propose an incremental plan rather than defaulting to a rewrite.
• Establish basic visibility into processing failures and production errors.
• Agree on the first set of critical product events and data definitions.

Days 31–60

• Implement the highest-priority architectural improvement, likely the Master Card versus trip-specific instance model.
• Improve capture reliability with validation, idempotency, retries, and clearer failure states.
• Add or improve background processing where needed.
• Add tests around critical capture, card, trip, and sharing flows.
• Document important decisions so another engineer can understand and maintain the system.
• Recommend the next phase for ShareLinks, group collaboration, creator tools, and behavioral data.

What we are looking for

Core experience

• Strong TypeScript and Node.js backend experience.
• Experience with Express or a comparable API framework.
• Experience designing document-database schemas with MongoDB or a comparable database.
• API design and third-party integration experience.
• Authentication, authorization, and role- or scope-based access control.
• Background jobs, asynchronous processing, queues, retries, and idempotency.
• Logging, monitoring, debugging, and production failure recovery.
• Automated testing and safe schema or data migrations.
• Evidence that you personally owned a meaningful backend in production.

Valuable, but not mandatory

• Next.js familiarity.
• Geospatial data, map APIs, or location search.
• Social-content parsing, scraping, or browser automation.
• Structured LLM output, validation, and model-provider fallbacks.
• Product analytics and event architecture.
• Real-time collaboration or WebSocket systems.
• Affiliate attribution or booking integrations.
• Consumer, creator, or travel-product experience.

We care more about backend judgment and production ownership than a perfect match to every tool in our current stack.

How you work

You may be a strong fit if:

• You investigate an existing system before proposing a rewrite.
• You can distinguish what Palette needs now from what may be useful after significant growth.
• You can explain architecture, risk, and trade-offs clearly to technical and non-technical teammates.
• You build with an early-stage budget and understand the operating cost of your choices.
• You are comfortable making progress from a high-level product goal rather than waiting for a complete technical specification.
• You communicate assumptions, decisions, progress, and blockers proactively in an asynchronous team.
• You care about user and business outcomes—not only technically interesting systems.
• You are willing to own routine maintenance and production reliability after the initial architecture work is complete.
• You hold strong technical opinions but change your position when evidence supports a better approach.

Why this is a founding-team role

You will not be joining simply to complete a backlog of backend tickets. You will:

• Own Palette’s backend as an ongoing product responsibility.
• Participate in product, data, and architecture decisions.
• Help prioritize new capabilities against reliability, technical debt, and user value.
• Shape the engineering practices and documentation that future hires inherit.
• Help evaluate, onboard, and mentor future backend contributors.
• Work directly with a non-technical founder and technical co-founder.
• Influence how Palette’s creator, group-travel, personalization, and monetization ideas become real systems.

We are looking for someone who wants to build Palette with the team over time—not treat Palette as another consulting client or temporary portfolio project.

Commitment and compensation

This is currently an equity-only, part-time role. Palette is pre-revenue and cannot offer a salary today. Please apply only if that arrangement genuinely works for your circumstances; we cannot guarantee a date when cash compensation will become available.

The anticipated equity range is 1%–3%, depending on experience, commitment, role scope, and mutual fit. The role begins with a 60-day mutual working period. Proposed equity, vesting, responsibilities, and long-term expectations will be reviewed and documented in writing as part of that process.

Most team members currently contribute alongside other professional or academic commitments. We expect approximately 8–15 dependable hours per week, one recurring team meeting, and consistent asynchronous communication. We do not track hours or prescribe a daily schedule; we agree on outcomes and expect open communication when availability, priorities, or timelines change.

How to apply

Apply through Wellfound and include concise answers to the following:

1. Describe one production backend you personally owned. What did it do, what did you build, and what broke after launch?
2. Describe a messy system you inherited. How did you decide what to fix, what to leave alone, and whether to rewrite anything?
3. How would you process a submitted social link asynchronously while preventing duplicates and recovering from partial failure?
4. Which technologies have you used that you would deliberately avoid at Palette’s current stage?
5. How would you keep an early production backend and analytics setup lean and affordable?
6. How many hours can you consistently commit, and what other work competes for those hours?
7. Why do you want to join a founding team rather than complete a defined consulting project?
8. What would happen to your Palette commitment if you received a demanding paid contract or full-time offer?
9. Share one code sample, architecture diagram, or public project that reflects your own backend work. Clearly explain what you personally built.

We prefer concrete evidence and honest trade-offs over a long cover letter or a list of technologies.