Early-stage. Building in public. Looking for people who want to shape it.
Spend Sense is still early — not a polished org with defined bands and start dates. If you're excited to help build a privacy-first personal finance product from near the ground floor, we want to hear from you.
Compensation and structure (equity, contract, paid, or a mix) are still being figured out. If a role interests you, email us — we will talk through fit and arrangements directly. This page gauges interest; it is not a formal job board with binding terms.
Roles we're gauging interest in
These are areas where help would matter right now. Reach out per role — we'll discuss fit and how we might work together. Nothing here is a binding offer.
We encourage you to reach out even if you don't check every box below — a lot of what's needed here is judgment and initiative, not a specific checklist.
For Flutter Developer, Social Media Manager, and AI Automation Specialist, contract or freelance engagement is also worth discussing — those roles can work well without requiring a full-time commitment up front. Reach out and we can talk through what fits.
Backend Engineer
Interest open
About the role
Today Spend Sense is fully on-device — local SQLite for data, flutter_secure_storage for auth, and no hosted backend at all. That privacy posture is intentional, but it also caps what we can ship: sync, account recovery, and push are blocked without a real server. At this stage one strong backend engineer reasonably owns building the API, securing it, and keeping it running — not three separate Security / DevOps / Backend hires a two-person team can't staff.
What you'd actually work on
Execute the planned Postgres migration (schema inventory and conceptual ERD already drafted in the app repo) — multi-tenant models, sync-friendly tables, and responsible handling of financial data
Replace local-only auth with a real hosted auth system while preserving the privacy bar users already expect
Stand up hosting and infrastructure end-to-end: deploy, monitor, and keep the API actually up
Own security practices for money data — encryption, least-privilege access, and threat modeling as part of shipping, not a later checklist
Unblock push notifications: "Remind" is a deliberate stub today because there is no backend to trigger APNs/FCM delivery
You might be a good fit if you…
You have designed APIs and relational data models that survived real traffic, not only demos
You are comfortable with Postgres (or similar) in production-minded work
You already think about auth, encryption, and least-privilege access before someone asks
You are willing to own security and hosting alongside API work — not only the happy-path handlers
Messy greenfield-to-production transitions energize you more than they scare you
We can ship the waitlist and the marketing site — we cannot yet answer which channel actually brings people in. There is no UTM or campaign attribution on the website today (only Vercel Speed Insights for performance). This role exists to close that gap and turn visitors into activated users with experiments and instrumentation, not core backend infrastructure.
What you'd actually work on
Wire UTM / campaign attribution end-to-end so we know which channels convert — currently missing entirely
Instrument waitlist and onboarding funnels with events we can actually trust
Ship and read A/B or multivariate tests on the surfaces that matter for conversion
Partner with product and marketing on what to measure, what to change, and what to kill
You might be a good fit if you…
You have instrumented funnels and read the results without drowning in vanity dashboards
You are comfortable running experiments end-to-end — hypothesis, ship, measure, decide
You can ship small web/product changes that move conversion, not only write analysis docs
You care more about clear metrics than impressive-looking charts
General product engineering across the marketing site, free tools, and app-adjacent surfaces. You'd move between front-end, back-end, and APIs depending on what unblocks the next ship. Early-stage means broad ownership and messy context-switching — capability breadth matters more than a single preferred language.
What you'd actually work on
Ship features across the website and tools that people use before they download the app
Connect front-end surfaces to APIs and services without waiting on a dedicated platform team
Keep security practices and deployment hygiene in the loop — not just the UI layer
Make hosting and infrastructure actually work end-to-end when something you ship depends on it
You might be a good fit if you…
You can move across front-end, back-end, and APIs — and aren't afraid of the parts people skip, like security practices and making sure what you deploy actually stays up
You have shipped features without a large platform team behind you
You are comfortable owning end-to-end: from UI through services to hosting and deployment actually working
You have practical judgment on when to polish vs. ship
The mobile app is Flutter and already in TestFlight Beta. This role is the native iOS edge — platform channels, App Store submission and review, and iOS-only polish that Flutter alone doesn't cover. You bridge the Flutter app and the Apple platform rather than owning the entire Flutter UI layer.
What you'd actually work on
Own App Store Connect, signing, entitlements, and review quirks through real submissions
Build and maintain platform channels / native modules where Flutter needs Apple APIs
Ship iOS-specific UX and performance polish that TestFlight testers actually feel
Partner with Flutter and backend work so store releases stay credible and repeatable
You might be a good fit if you…
You have shipped native iOS work in Swift (UIKit or SwiftUI)
You know your way around App Store Connect, signing, and review surprises
You have worked with platform channels or native modules in a cross-platform app
You notice iOS-specific UX and performance details others gloss over
Android has no shipped version yet — genuinely zero Android release work exists. This is ground-floor ownership of getting Spend Sense onto Android from the existing Flutter codebase, not maintenance of a live Play Store listing.
What you'd actually work on
Define and execute the path from the Flutter codebase to a credible first Play Store release
Own Play Console, signing, store requirements, and first-release hygiene
Handle Flutter / native Android interop where platform APIs are required
Set the quality bar for Android so the first ship is trustworthy, not a throwaway build
You might be a good fit if you…
You have shipped native Android work (Kotlin preferred)
You are familiar with Play Console, signing, and store requirements
You are comfortable standing up a first release, not only iterating on a mature app
You are willing to work with Flutter/native interop where needed
Join our existing Flutter developer as a peer — a second engineer on the mobile product, not the founding mobile hire. You'll share day-to-day Flutter work in the live codebase (screens, flows, polish that TestFlight users already see) and help burn down concrete architectural and UX debt together.
What you'd actually work on
Pair on cleaning up dead domain-layer stubs that still throw UnimplementedError while real logic lives in services and presentation — implement or delete so the architecture stays honest
Extract duplicated contact-search logic shared by the split wizard and Create Squad flow into one implementation both can use
Close delete-undo gaps with your peer: Budgets, Categories, Vacation Trips, Goals/Debts, and Squads currently delete with no recovery path (only Transactions and Receipts do undo correctly today)
Fix remaining theme-brightness bugs where dark-mode colors still leak into light mode (named cases tracked in session notes, including transaction list error state, vacation error banner, settlement suggestion card, and spending-pace chart)
You might be a good fit if you…
You have shipped production Flutter / Dart features, not only tutorials
You collaborate well with another engineer already deep in the codebase — sharing ownership, not taking it over
You care about clean UI implementation and state management without perfectionism blocking ships
You treat testing and release hygiene as part of the work, not optional extras
A narrowly scoped role: automate a few painful internal workflows with AI tooling — not an open-ended mandate to "add AI everywhere." At this stage we don't have a separate PM or AI-infra function, so a focused specialist who ships named automations is the right fit. Keep the blast radius small and the outcomes checkable.
What you'd actually work on
Build a triage pipeline for TestFlight / App Store user feedback — classify, categorize, and route items so founders aren't reading every review raw
Design the waitlist-to-onboarding email automation that can go live once a hosted backend exists (templates, triggers, and handoff points — not a full CRM platform)
Document the toolchain and handoff so a small team can run and adjust the workflows without you in every loop
Propose the next one or two automations only after the first workflows are reliable — resist scope creep into product AI features
You might be a good fit if you…
You have shipped real automations with modern AI / LLM tooling, not only demos or prompt playgrounds
You prefer narrow, named workflows with clear success criteria over vague "AI platform" builds
You can choose a pragmatic toolchain and explain tradeoffs to non-specialists
You are comfortable iterating with founders who want results fast and documentation that survives you
Focus on brand identity — logos, emblems, visual system, and the look that shows up everywhere we show up. This is explicitly not a product/UX design role; app interface design is not the ask. Without a coherent system, we default to generic fintech looks (we've already had to walk back gradient-text treatments that could belong to any brand).
What you'd actually work on
Build a clear visual identity system: marks, type, color, and usage rules a small team can follow
Deliver assets ready for web, social, and App Store / Play Store use
Replace one-off treatments with a look that is recognizably Spend Sense, not generic fintech purple
Partner with founders who have strong opinions and unfinished briefs — iterate until it lands
You might be a good fit if you…
You have a strong portfolio in logos, marks, and brand systems
You have taste for clear, modern identity — and you notice when something looks like every other finance app
You can deliver production-ready assets across web, social, and store surfaces
You are comfortable iterating with founders who have strong opinions and unfinished briefs
Spend Sense already has presence across Instagram, TikTok, X, Threads, Facebook, and Reddit (linked from the site footer), plus Discord channels for bug reports and feature requests. What we don't have is consistent ownership. This role gives that presence a real voice for a personal-finance audience while we build.
What you'd actually work on
Own content and community across the existing channels — not scattershot founder posts
Build a platform strategy for where this audience actually spends time, and drop what doesn't work
Write and package short-form content people finish — useful, human, not corporate fluff
Engage comments and Discord bug/feature channels so feedback reaches product without drowning founders
You might be a good fit if you…
You have run social for a product or creator brand with your hands on the accounts
You can write and package short-form content that people actually finish
You have judgment about which platforms matter for a given audience
You are comfortable engaging with comments and community without sounding like a press release
Not hiring for these yet — listed so you know what's on the horizon once users are in the product, or once real money movement ships.
Customer Support Representative
Not an immediate opening
About the role
Needed once the app is live — not an immediate opening. When users are in product, someone has to answer questions, triage bugs, and turn confusion into clearer docs and product feedback. We're listing it early so the right people know it's coming.
What you'd actually work on
Answer user questions clearly and patiently once the app is public
Triage bugs and route real product issues to engineering with useful context
Turn repeated questions into documentation and help-center improvements
Surface patterns from support conversations that should change the product
You might be a good fit if you…
You write clearly and patiently, especially with people who are stressed
You have experience in support, success, or community help roles
You are comfortable with ticket tools and turning repeats into documentation
Needed once real money movement is live — bank linking and/or payment processing — not before. At that point fraud monitoring, regulatory compliance, and risk review become real functions, distinct from general product security. Fintech peers treat this as its own lane; we're listing it early so people who do this work know it's on the horizon.
What you'd actually work on
Stand up fraud monitoring and review workflows once money actually moves through the product
Own regulatory compliance obligations that kick in with bank linking and payment processing
Build risk-review processes founders and engineering can follow without guessing
Partner with backend and product so controls ship with money-movement features, not as a retrofit
You might be a good fit if you…
You have worked in risk, compliance, or fraud in a fintech or payments context
You can translate regulatory requirements into practical product and ops controls
You are comfortable building processes from near-zero, not only maintaining a mature program
You communicate clearly with engineers and founders who are not compliance specialists