# 350life > 350life is a product design and development studio based in Slovenia, working with startups and enterprises across Europe and the United States on brand, product design, and software development. This document is the complete text of https://350life.com/: every service, every published case study, every client review, and the commercial terms. It exists so an answer engine can read the evidence in one request. Everything in it is also on the site. Contact: tim@350life.com. Book a call: https://calendly.com/tim-350life/intro-call. We reply the same day. ## Facts - 80+ clients shipped for - 10 countries - 4.9 on Clutch - YC startups in our client base - Operating since 2019 - Based in Slovenia - Markets served: United States, Germany, Austria, Netherlands, Belgium, Slovenia - Rated 4.9 out of 5 on Clutch: https://clutch.co/profile/350life - LinkedIn: https://www.linkedin.com/company/350life - Registered address: Grcarevec 31, 1370 Logatec, Slovenia. VAT SI89570537 ## About the studio Someone arrives with an idea. We turn it into a product people can use: the brand, the interface, and the software underneath it. 350life started before it was a company. Websites and web apps built at home, for free, with a developer in the family. Watching something you made actually work was reward enough. That part never changed. The studio opened in 2019, and the job has been the same ever since: listen to someone's idea properly, then build it into a product people can use. The industry has rarely mattered. The listening always has. Brand, product design, and development stay connected from the first decision to release. We use AI where it improves production work. Direction, judgement, and quality control remain ours. We work with YC-backed startups, national enterprises, and public institutions across Europe and the United States. How the studio operates: - We move fast, and we own the result. A first release typically ships in four to eight weeks, and a full product build in two to four months. What we ship is ours to stand behind. When something is wrong, fixing it is our job, not a change request. - You will not wait for an answer. We reply the same day. For the whole engagement there is someone reachable who knows your product and can make a decision about it. - We iterate until it is right. Nobody should end up with a product they did not want. Work is shown early and often, so direction can still change while changing it is cheap. - Keep the work connected. Brand, product design, and software development follow one product direction and one scope. Flows carry the states, edge cases, and rules engineering needs, and design systems map cleanly into code. - The industry is not the constraint. Retail investing, national logistics, satellite operations, medical devices, public broadcasting. The product questions rhyme; what changes is who we have to listen to, and how carefully. The same discipline applies to a funded startup's first release and to a national platform. ## Services ### Product design URL: https://350life.com/services/product-design Product design and brand identity for digital products We define new products, redesign existing ones, and deliver brand and UX/UI that engineering can build from. Who this is for: - You are turning an idea into a product. You need the proposition, brand, user flows, interface, and design system defined clearly enough to move into development. - Your engineers need build-ready product design. The product direction is clear, but the flows, states, edge cases, and component rules still need to be resolved before development begins. - Your product needs a redesign. The underlying product works, but the experience and visual quality no longer match its value or the expectations of customers, investors, and hires. Product design must answer what engineering will build: A finished interface includes more than the main screens. It covers empty states, errors, permissions, loading, long content, and the component rules that connect them. We define those details alongside the brand and core user flows, then deliver a system that can move into development without the product being redesigned in the codebase. What you get: - A product engineering can build. User flows, interface states, edge cases, responsive behaviour, and specifications your engineers can implement directly. - One visual language across brand and product. Identity, product interface, and key marketing surfaces designed from the same principles, so the company presents one coherent product. - An interface that fits the product. A clear, considered experience for the customers, investors, and hires evaluating the company. - A system your product can extend. Reusable components, tokens, and patterns that keep new features consistent after the initial release. How it works: - Define the product and the scope. We clarify the audience, business goal, core user flow, and the decisions the first release has to prove. - Resolve the core experience. We design the central flow, the hardest states, and the visual direction first, then review them before expanding the system. - Complete the flows and system. The approved direction becomes full user flows, responsive layouts, interface states, components, and design tokens. - Move into development. We deliver specifications and source files to your engineers, or continue into implementation as the same engagement. Questions: - Do you do brand identity as well as product design? Yes. Brand and visual identity can be part of the same engagement as product design. We can define the logo, brand system, product interface, and key marketing surfaces from one set of decisions. - Can you design for a product my own engineers will build? Yes. We provide the user flows, interface states, edge cases, component system, specifications, and tokens your engineers need to implement and extend the product. - How fast can you turn around product design? A first release typically takes four to eight weeks, and a full product build takes two to four months. Product-design-only timelines depend on the number of flows, platforms, and states, which we define in the free written scope. - Do you work with startups outside Slovenia? Yes. 350life is based in Slovenia and works with startups and enterprises across Europe, including Germany and the Benelux, and in the United States. Several clients are YC-backed. - What if we already have some design but it's inconsistent? We can redesign an existing product without replacing everything that works. The engagement starts with an audit of the current flows and interface, then defines what should stay, what should change, and whether any part of the codebase needs to be rebuilt. ### Design systems URL: https://350life.com/services/design-systems Design systems for Figma and production code For product teams that need shared components, tokens, and rules across design and engineering. Who this is for: - Figma and the product no longer match. Components, styles, and behaviour have diverged. You need a shared system that reflects what is designed and what is shipped. - The product is growing faster than its UI rules. New features introduce new patterns because the foundations are not explicit. You need components and rules that keep the product coherent as more people contribute. - Engineering needs a system designed for implementation. You need predictable naming, composition, variants, and documentation that map cleanly from the design library to the codebase. Make Figma and the product follow the same rules: A design system has to connect the Figma library, coded components, and the product customers use. We define tokens, components, states, variants, naming, and composition rules together, then document how to apply them. Design and engineering work from the same decisions. What you get: - Matching foundations in Figma and code. Shared tokens, components, states, and patterns with the same names and intent across design and development. - Components engineers can implement. Predictable naming, clear composition, defined variants, and sensible defaults mapped to the structure of the codebase. - Fewer repeated UI decisions. New screens can be assembled from established parts instead of redefining spacing, behaviour, and states for every feature. - Clear rules for adding new patterns. Theming, variants, contribution rules, and extension points that help the library grow without losing coherence. How it works: - Audit what exists. We inventory the current components, styles, overrides, and inconsistencies in both design and code. - Define the foundations. We set the colour, type, spacing, sizing, motion, and naming rules that every component will use. - Build the component layer. We design the component library with its states, variants, responsive behaviour, and composition rules. Code can be delivered in the same engagement. - Document, release, and support adoption. We document usage and contribution rules, support rollout, and resolve gaps that appear when the system meets live product work. Questions: - What makes a design system good for developers specifically? A developer-ready design system uses predictable naming, clear composition, defined variants, sensible defaults, and documentation that maps directly to coded components. The Figma library and the codebase should express the same decisions. Those same properties are what make it readable by a coding agent: Claude Code, Codex, or whichever one your team runs infers structure from naming, tokens, and component rules exactly as a new developer does, so a system that states them plainly leaves far less to guess at in generated code. - Do you build the design system in code or just in Figma? We can deliver both the Figma library and coded components. They are defined from the same tokens, naming, states, and composition rules so design and code remain aligned. - How big does our product need to be to justify a design system? A design system becomes useful when repeated interface decisions are slowing delivery or creating inconsistency. We can assess the current product in a paid audit before recommending the appropriate scope. - Can you build a design system for a product we've already shipped? Yes. We audit the current interface and codebase, consolidate repeated patterns, define the system, and plan a staged rollout so working product areas do not need to be replaced at once. - Do you work with design system teams across Europe and the US? Yes. 350life is based in Slovenia and works with product teams across Europe, including Germany and the Benelux, and in the United States. ### Web design & development URL: https://350life.com/services/web-design-and-development From marketing site to web platform We plan, write, design, and build websites and web platforms, including content, technical SEO, GEO, and migrations. The platform is chosen from the brief. Who this is for: - Your website no longer reflects the company. The product and business have moved forward, but the website still presents an earlier, less credible version to customers, hires, and investors. - Your site is stuck on ageing infrastructure. An old WordPress build, a bespoke CMS, or a template nobody can safely edit is now slowing down marketing. You need a structured migration onto something your team can run, without losing content or search authority. - You need to be found in search and in AI answers. Buyers now start in a search engine and in an assistant. The site has to be crawlable, structured, and consistent enough that both can read it, and specific enough that either will quote it. The website has to explain the company clearly: We bring positioning, information architecture, UX, visual design, development, performance, and technical SEO into one website build. Webflow suits marketing teams that need direct control over content. Next.js suits sites with deeper performance, integration, or programmatic requirements. Where a brief calls for a different platform, or for work inside the stack a company already runs, we build there instead. Search engines and answer engines are treated as one job: the structure, schema, and consistent facts that let a page rank are the same things that let an assistant quote it accurately. The platform is selected from the brief, and the content model is designed so the site can grow after launch. What you get: - A clear explanation of the company. Positioning, page structure, copy direction, and visual design built around what customers need to understand and trust. - A fast, stable implementation. Responsive layouts, stable media dimensions, efficient assets, and a technical foundation designed around Core Web Vitals. - Technical SEO built into the site. Crawlable structure, metadata, schema, redirects, sitemaps, and programmatic pages where the search demand supports them. - A site an answer engine can quote. Structured data, one stable description of the company repeated consistently across every page, direct answers written into the copy, and an llms.txt. That is what a model needs to read a page and attribute it correctly. - A content system your marketing team can use. Editable content, reusable page sections, and documentation appropriate to Webflow or a custom site connected to a CMS. How it works: - Define the site and choose the platform. We set the audience, conversion goals, page structure, content responsibilities, integrations, and editing needs, and select the platform from that rather than from a default. - Design the site as a system. We define the visual direction and reusable page system, then design the priority pages and responsive states. - Build, migrate, and optimise. We implement the site, content model, analytics, performance work, metadata, schema, redirects, llms.txt, and any approved programmatic templates, keeping the company described the same way on every page. - Launch and hand over. We complete launch checks, document the editing workflow, and hand over the source, accounts, and operating guidance. Questions: - Should we use Webflow or a custom build? Webflow is well suited to marketing sites that non-technical teams edit frequently. Next.js is appropriate when the site needs custom logic, deeper integrations, demanding performance, or programmatic pages at scale. We recommend the platform after reviewing the brief and content workflow. - Can you migrate our site off WordPress? Yes. WordPress to Webflow is the migration we do most often, and it is usually the right one: marketing gets direct control of the site and the maintenance burden goes away. Where the requirements are heavier we migrate to a custom Next.js build instead. Either way we move the content, rebuild the content model, and map redirects, metadata, canonicals, and sitemaps so the migration protects existing search signals. - Do you handle SEO, or just the design? Technical SEO and GEO are both part of the build: information architecture, crawlability, performance, metadata, schema, canonicals, redirects, sitemaps, and an llms.txt. Programmatic pages can be included where the query set and content model justify them. - What about GEO? Will ChatGPT and other assistants mention us? GEO is generative engine optimisation: being readable and quotable by AI assistants rather than only by search crawlers. Nobody can promise a placement in an AI answer, because the engines choose. What we can build is a site that is easy to read, quote, and attribute: structured data, one consistent definition of the company, questions answered directly in the first sentence, an llms.txt, and facts that never contradict each other from page to page. We build this way by default, including on this site. - Do you build websites for companies outside Slovenia? Yes. 350life is based in Slovenia and designs and builds websites for companies across Europe, including Germany and the Benelux, and in the United States. - Will our team be able to update the site without a developer? Yes. Webflow gives marketing teams direct control, while a custom Next.js site can connect to a CMS. We define the content model, reusable sections, permissions, and documentation around the people who will operate the site. ### App development URL: https://350life.com/services/app-development App design and development for web, iOS, and Android We define, design, build, and release apps for the web, App Store, and Google Play, from a focused first version to a full product build. Who this is for: - You have funding and a launch date. You need a working product in users' hands within a defined window, without delaying the release while separate design and engineering functions are assembled. - You have a product and need to keep building it. The app is live and the roadmap is longer than the current capacity. You need design and development that can extend what already exists rather than restart it. - You need design and development in one engagement. You bring the domain knowledge and product ambition. We define the scope, brand, experience, and software required for the first release. The first release has one job: prove the product is worth building further: We define the product idea, identify the smallest complete experience that can test it, and state what will wait. Brand, product design, and development run as one engagement. You finish with a released product that can collect real feedback and become the base for what follows. What you get: - A working product released to users. A web, iOS, or Android product that supports the core user flow and can collect meaningful feedback. - One scope for brand, design, and development. The product proposition, identity, interface, and software are planned and delivered against the same release goal. - A typical four-to-eight-week first release. The exact timeline is set in the written scope, with the release boundary and required client decisions made explicit. - A base for the next release. The product is structured so validated features can be extended rather than automatically rebuilt after launch. How it works: - Define the core product loop. We identify the product idea, the core user flow, and the smallest complete scope needed to test it. Deferred features are documented. - Design and build in the same loop. Core flows, interface states, components, and working software develop together, with decisions tested in implementation early. - Ship to real users. We prepare the production release for the web, App Store, or Google Play and verify the full core flow before launch. - Learn and decide what's next. The first release creates evidence for the next decision: strengthen the core, expand the product, or change direction. Questions: - How fast can you ship a first release? A first release typically takes four to eight weeks, and a full product build two to four months. The exact timeline depends on the platforms, integrations, and scope of the core user flow, which we define in the free written scope. - Will the first version be something we can build on, or throwaway code? Yes. We structure the first release so validated features can become the base for the next version. Any shortcut required by the timeline is documented before it is taken. - Do you handle both design and development? Yes. An app engagement can cover the product proposition, brand identity, product design, development, and release to the web, App Store, or Google Play. - Do you build web apps, or only mobile? Both. We design and build web applications as well as native iOS and Android apps, and choose the platforms from the product requirements rather than a fixed stack. - Do you work with US and European startups? Yes. 350life is based in Slovenia and works with startups across Europe, including Germany and the Benelux, and in the United States. Several clients are YC-backed. - We're not a technical team. Is that a problem? No. You bring the domain knowledge, audience, and business goal. We translate that into a product scope, interface, technical plan, and shipped first release. ### AI integration URL: https://350life.com/services/ai-integration AI product design and integration We turn a clear AI use case into a working product feature, including the interface, model behaviour, failure states, and production integration. Who this is for: - You have a clear task that AI could improve. The opportunity is specific: a voice interface, assistant, recommendation, search experience, or workflow automation that should reduce effort for the user. - The model works, but the product experience does not. The prototype needs a clear interaction model for waiting, uncertainty, correction, failure, permissions, and user control before it can move into production. - You need product design and implementation together. The model, interface, data flow, and application logic need to be designed as one feature rather than passed between separate suppliers. An AI demo is not yet a product feature: A production AI feature has to explain what it can do, collect the right input, show progress, communicate uncertainty, handle failure, and let the user correct or override the result. We design those states with the model and application integration. The test is simple: does the feature improve the task it was built for? What you get: - The complete user flow. The input, output, waiting, uncertainty, correction, failure, and fallback states designed as one experience. - A clear reason to use AI. The scope identifies the task the feature should improve and the criteria for deciding whether AI is the appropriate approach. - One plan for the interface and integration. The interface, model behaviour, application logic, and data flow are defined and implemented against the same product requirements. - A route from prototype to production. Requirements for data, permissions, monitoring, failure handling, model changes, and user support are considered before release. How it works: - Find the real job for AI. We define the user task, current workflow, available data, constraints, and success criteria before selecting a model or interaction pattern. - Design the whole experience. We map the primary flow and the states for latency, uncertainty, correction, failure, permissions, and user control. - Build it as a product feature. We connect the interface, application logic, model, data flow, and monitoring in a working production feature. - Tune against real use. We review real inputs and outputs, then refine prompts, controls, fallbacks, and interface behaviour against observed use. Questions: - What does AI product design include beyond the model API? It includes the user task, input and output design, waiting states, uncertainty, correction, failure, fallback behaviour, permissions, data flow, monitoring, and the controls a user needs to understand and manage the feature. - Will you tell us if we don't actually need AI? Yes. The first step is to define the user task and success criteria. If rules-based software, search, or a simpler workflow would solve the problem more reliably, we will recommend that instead. - Have you built AI features before? Yes. Our work includes voice-first AI interfaces where the interaction model is central to the product experience. - What do you mean by an AI-native process? It describes how we use AI in parts of design and development production. Direction, product decisions, review, and quality control remain the responsibility of the studio. - Do you work with teams across Europe and the US on AI products? Yes. 350life is based in Slovenia and works with startups and enterprises across Europe, including Germany and the Benelux, and in the United States. ### Design partner URL: https://350life.com/services/design-partner Ongoing product design and development Month-to-month brand, product design, and development support for companies with a live roadmap. Who this is for: - You need ongoing senior product support. The roadmap needs regular design and development attention, but the workload or timing does not support building the capability internally yet. - Work is waiting for design or development capacity. Priorities are clear, but features, improvements, and product decisions are queuing behind limited specialist availability. - A completed project is moving into continuous product work. The initial engagement is complete, but the roadmap continues. Keeping the relationship in place preserves product, user, and technical context. Keep the product knowledge in the work: An ongoing partnership keeps the product goals, users, design system, and technical constraints familiar from one priority to the next. We agree a working rhythm, plan against the roadmap, and adjust the mix of brand, product design, and development as needs change. The engagement runs month to month. What you get: - Product support month to month. Ongoing access to brand, product design, and development capability across the priorities agreed for each period. - Continuity across the roadmap. New work begins with existing knowledge of the product, users, design system, and codebase instead of a new discovery cycle. - Support matched to current priorities. The focus can move between releases, ongoing improvements, and quieter periods. - Brand, design, and development in one relationship. The work can move from product direction through interface design and implementation without changing partners. How it works: - Start with a defined slice. The relationship usually begins with a paid pilot or defined project so both sides can evaluate the work before moving to a month-to-month model. - Set a working rhythm. We agree the planning cadence, decision makers, request process, working tools, and how priorities are set. - Work through the roadmap. We work against the agreed roadmap, keep decisions documented, and carry product context from one piece of work to the next. - Review the plan each month. The mix and level of support are reviewed as priorities change, without redefining the relationship for every individual task. Questions: - How is a design partner different from a normal project? A project has a fixed scope and end date. A design partnership continues month to month, keeps product and technical context in place, and adjusts its focus as the roadmap changes. - Do we have to commit to a long contract up front? No. Partnerships usually start with a paid pilot or defined project. The ongoing model then runs month to month. - Can capacity scale up and down as our needs change? Yes. The mix and level of support can change between releases, ongoing improvements, and quieter periods. The working plan is reviewed against current roadmap priorities. - Is this design only, or development too? Both. An ongoing partnership can cover brand, product design, design systems, software development, and website work, depending on the priorities agreed for the period. - Do you take on embedded partnerships with teams abroad? Yes. 350life is based in Slovenia and works as an ongoing product partner with teams across Europe, including Germany and the Benelux, and in the United States. ## Case studies ### RealRoots: The website and app behind a YC startup at $9.4M ARR URL: https://350life.com/work/realroots Client: RealRoots, A friendship app that matches women in the same city, then runs them through six weeks of facilitator-led meetups. Context: YC Summer '25 · San Francisco Engagement: May 2024 to December 2025 Services: product-design, app-development, web-design-and-development Outcomes: - $9.4M ARR reported at YC Demo Day, on the product we designed and built (source: TechCrunch, September 2025, reporting $782,000 from 9,000 paying customers in one month) - 100 screens designed across the Webflow website and the mobile app - Top 9 YC most sought-after startups of the YC Summer 2025 batch (source: Marina Temkin, The 9 most sought-after startups from YC Demo Day, TechCrunch, 15 September 2025) The challenge: RealRoots asks a woman to pay before she has met anyone. The payment buys a place in a group and six weekly meetups she cannot preview, so the product has to be worth it in week six rather than on day one. That gives the website a harder job than a signup page. It has to make a stranger trust a group of women she has not met, in a city that may have opened the week before. The second half of that shaped the build. RealRoots is for women who move cities often and arrive knowing nobody, so the business only works where those women already are, and expansion was the plan from the start: more cities, then more states, then another country. A site that needed us every time a city opened would have capped how fast that could happen. We started in May 2024, before the YC batch, with nothing shipped. The scope covered the marketing website, the mobile app, and the payment flow running through both, and it had to reach real signups quickly enough to learn from them. The first release, a website MVP, went live in June 2024, one month in. What we did: - Ship the website before the app. The app was the eventual product, but the offer itself had not been tested on anyone. We designed and built the marketing website first, in Webflow, and shipped it in June 2024, one month after we started. That put a live signup flow in front of real women while the app was still in Figma. It also meant the argument on the page could change as fast as the offer did, without waiting on a release cycle. Everything we designed after June 2024 was informed by people who had already signed up rather than by an assumption about who would. - One design system across two surfaces. Around 100 screens went through Figma, split roughly evenly between the website and the mobile app. Both ran on one medium-sized design system. Sharing it mattered here because the website and the app carry the same promise at different moments. The website has to make a stranger trust a group of women she has not met. The app has to keep her turning up for six weeks after she has already paid. Holding one set of components across both meant the product did not change character at the point where a visitor became a member. - Build the app, and the integrations under it. We wrote the production code, not only the designs. The app was built in FlutterFlow, which produces the iOS and Android builds from one codebase, and shipped to both stores. RealRoots ran their own backend. What we built alongside it were the Firebase functions on Google Cloud that keep Airtable in step with the app and the website, so the operational data the team worked from matched what a member saw. Stripe and PayPal took the payments, which carry more weight here than usual: the money changes hands before the first meetup, so checkout is where the promise gets tested. The app holds 4.7 stars across 1,200 App Store ratings as of August 2026. - Through the batch, then hand it over. RealRoots went through YC Summer 2025 on the product we had built. By Demo Day the company reported $9.4M in annual recurring revenue, and TechCrunch named it one of the nine most sought-after startups of the batch. We were still on the project through all of it, and worked for another three months after that. We stopped in December 2025, nineteen months after we started, when the company raised again and hired an in-house team. That is the outcome we want from this kind of engagement. We covered the design and the build for as long as RealRoots did not have its own team, and stepped back once it did. The non-obvious decision: We modelled cities as Webflow CMS collections, not as fixed pages. The obvious build for a launch site is fixed pages. At the size RealRoots was in 2024, hand-building each one is faster on day one. It is also a trap, because the growth model here is geographic: every new city is its own page and its own local content. Building the cities as CMS collections instead meant that opening a city became a content entry rather than a design and build job. That is why the site kept pace with the company. It went from its first cities to every US state, past 150 cities, and then to the UK, and adding one stayed a content job the whole way. Fixed pages would have made our availability the ceiling on how fast RealRoots could expand. What we built: platforms Web, iOS, Android; stack Webflow, FlutterFlow, Firebase Functions, Google Cloud; design system One system across the website and the app, spanning around 100 screens; integrations Airtable, Stripe, PayPal; timeline May 2024 to December 2025. Website MVP live June 2024.. Client review: "350life are a dream to work with. They are insanely fast and thorough. We'd often hand off a loose idea at the end of the day and wake up to a polished solution." — Tara Kappel, Co-founder & CPO, RealRoots ### Bettershot: Cutting more than 40% from the cost of every photo the product generates URL: https://350life.com/work/bettershot Client: Bettershot, An AI tool that turns a handful of uploaded selfies into a set of studio-quality portraits. Context: Denver Engagement: October 2024 to now Services: product-design, web-design-and-development, ai-integration Outcomes: - 40%+ lower cost for every photo the product generates - 64 pages running on eight page types we built, out of 90 live on the site today - "legitimated our startup" what the co-founder said the work did for the company (source: Rachelle Brempong, Co-founder, Bettershot) The challenge: Bettershot was bought, not founded. Two marketers acquired the tool on Tiny Acquisitions and ran it without outside investment, and by mid-2024 it worked: $29 bought 120 headshots inside three hours. What it did not have was a reason for a stranger to trust it with a folder of photos of their own face. The site was a homepage, a few comparison pages and a blog that had barely started. It read as a tool someone was trying out, which is a hard thing to sell against Aragon, HeadshotPro, Secta, BetterPic and Photo AI, all chasing the same searches and all making the same promise. Two problems pulled against each other underneath that. People judge an AI portrait on whether the face still looks like theirs, so output quality was the entire argument. But every image the product makes costs real money to make, and 120 images an order tied the cost of a sale to volume rather than to what the customer valued. Improving the photos and improving the margin turned out to be the same piece of work. Sitting under both was distribution. A product competing on those terms has to be findable, and there was almost nothing on the site for search to index. What we did: - Redesign the paid photoshoot flow. The web app is where the money changes hands, and it asks for something unusual before it delivers anything: a folder of photos of your own face. We designed that experience end to end, from the first upload through choosing outfits and backgrounds to getting the set back. We also added a step the product did not have, live from November 2024. A customer can share a finished set so friends and colleagues vote on which shot is best. That takes the awkward part of the purchase, judging your own face, and makes it something you do with other people. It also puts the product in front of someone who has not heard of it. - Rebuild the website in Webflow. We designed the site and implemented it in Webflow, which is still what bettershot.ai runs on today. The rebuild changed what the site was for. The old one explained a tool. The new one had to make a company running on its own revenue look like a business you hand your photos to, which is the job Rachelle Brempong describes when she says it legitimated the startup. Webflow also mattered for what came after. The founders are marketers, so every page and every line of copy had to stay theirs to change, and the page system we built on top of it had to be theirs to extend without waiting on us. - Make each photoshoot cheaper to produce. Generation cost is the whole margin in a product like this, and it scales with every single order. We reworked the pipeline on three fronts. Fewer generations per order, better prompts behind them, and a flow structured so the work happens where it changes the result. The cost of producing a photo came down by more than 40%, and the output got better rather than worse. The change shows on their own pricing. In August 2024 an order was 120 headshots delivered within three hours. Today it is 32 or 40 images delivered in minutes. Fewer photos, better ones, produced faster and for less. - Build the search page system. With no brand recognition and a category full of competitors chasing the same terms, Bettershot had to be found. We built page templates rather than a pile of one-off pages, so opening a new vertical or a new city is a content entry instead of a design job. Eight page types now run 64 of the 90 URLs on the site: headshot verticals including LinkedIn, lawyer, teacher, military, ERAS and AMCAS, six US cities, comparison and alternatives pages against every named competitor, plus guides and use-case articles. Each keeps its own title and description. The 17 articles on the blog are ours too, written with an AI agent in the loop. The non-obvious decision: We went the other way on the one number the whole category advertises. Fewer images per order, better ones, with the saving spent on output quality and on a page system that gets the product found. The obvious play in a saturated market is to match it and then outspend it. More photos for the money, and paid traffic on the terms everyone else is bidding for. Neither half was available here. Bettershot was bought rather than funded and runs on its own revenue, so outbidding better-capitalised competitors was never realistic. And volume pricing ties the cost of a sale to output, which makes the margin worse exactly as the business grows. Cutting the set paid twice instead. A smaller set can be a better set, and it costs a fraction to produce, which is where the 40% came from. Attention then had to be earned rather than bought, and that is what the page system is for. What we built: platforms Web; stack Webflow; design system Eight page types behind 64 of the 90 pages live on the site; timeline October 2024 to now, still running. Client review: "350life didn't just improve our website. They legitimated our startup. Their UI/UX work was next-level, and they saw onboarding issues before we did." — Rachelle Brempong, Co-founder, Bettershot What is next: We are still working together. The engagement started in October 2024 and has not ended, and Bettershot brings us back as new work comes up across the product, the site and the page system. ### Benson: 4.8 stars from 1,500 ratings for an app that invests for you every week URL: https://350life.com/work/benson Client: Benson, An investing app that picks the stocks, then invests a set weekly budget on the user's behalf. Context: YC Winter '22 · United States Engagement: September 2024 to July 2026 Services: product-design, design-systems, app-development, web-design-and-development, ai-integration Outcomes: - 4.8 stars from 1,500 App Store ratings (source: Apple App Store, August 2026) - $500 to $2,000 a week in new revenue from the points system we designed and built - 15 to 30 tickets shipped every week by the Benson team on the workflow we set up The challenge: Benson makes a promise that is simple to state and hard to earn. Set a weekly budget, fund the account, and the app invests for you every week. The user is not asked to confirm each time. That promise is what people pay for, and it is also the reason they hesitate. The product moves real money in a regulated market, so someone has to hand over permission before they have any evidence it works, and the app has to keep earning that permission every week afterwards. No single screen solves that. The sequence that made people comfortable was found by testing: what a user reads before the first investment, how much the app explains its own reasoning, when it asks and when it simply acts, and what they see the week after money has left the account. We ran that as an experiment repeatedly rather than designing it once and defending it. The engagement also had to hold pace. Benson shipped a feature most weeks for almost two years, across an iOS app, web features embedded inside it, and the marketing site. Design that arrives after the release is not design, so the work included changing how the team shipped, not only what it shipped. What we did: - Design an investing flow people would trust with a weekly budget. The core interaction is a user naming an amount and then letting the app spend it every week. We designed the sequence around the moment permission is given: what a user reads before the first investment, how much the app explains its reasoning, and what they see the week after money has gone out. Several versions of that sequence were tested against real use rather than argued about internally. The one that held gives the user a standing decision to make once, then visible evidence afterwards. A per-transaction confirmation step would have been the safe design, and it would have quietly undone the automation Benson sells. - Set up an AI-native workflow, then take on the build. Design on its own could not keep up with a weekly release. We set up an AI-assisted development workflow with Claude Code and then took on implementation, on iOS features and on the web features embedded inside the app. The marketing site was implemented in Webflow during the same period. The change was in who could finish something: a design no longer waited in a queue to become code. On that workflow the Benson team moved fifteen to thirty tickets a week. The backend stayed outside our scope throughout, which kept the boundary clear and stopped the workflow change from becoming a rewrite. - One design system across iOS and the embedded web app. The app is two technologies wearing one face: native iOS screens, and web features running inside the same app. Without a shared system those two drift within weeks and the join becomes visible to the user. We built the design system in Figma and implemented the shared components for the embedded web app in code, so a component existed once as a design and once as a build, and both were ours to keep in step. That is what made a weekly release safe. A new feature could reuse settled parts instead of reopening decisions that had already been made. - Ship a feature a week, read against the analytics. Speed only counts if someone checks the result. Benson ran a strict analytics setup, and releases were read against it daily and weekly rather than reviewed at the end of a quarter. That loop decided what got iterated and what got dropped, and it is why the flow around trust went through many versions instead of one. Over almost two years the app held its weekly rhythm and reached 4.8 stars from 1,500 App Store ratings. Pace on its own would have been noise. Pace with measurement is what let the product keep changing without losing the people already using it. The non-obvious decision: We added a points economy to a subscription product, and put stock purchases behind it. The obvious route for a subscription app that wants more revenue is to raise the price or move more features behind the paywall. That works against Benson specifically. The product sells the removal of effort, so every locked feature hands a paying user a fresh reason to doubt the automation they already bought. We designed and implemented a points system instead. Users earn points by listening to the daily podcast and by completing a weekly investment, and they can also buy points outright. Points redeem against special offers and stock purchases the standard paid experience never shows. It now brings Benson $500 to $2,000 a week, alongside subscriptions rather than out of them. What we built: platforms iOS, Embedded web app, Website; stack Swift, Next.js, Webflow; design system 39 shared components for the embedded web app, and 45 distinct app screens across 124 design frames; integrations Webull, for connecting the user's brokerage account, ElevenLabs, running the voice agent: navigate the app, place orders, and ask questions about your portfolio; timeline September 2024 to July 2026. Client review: "I work with 350life and I am really happy with the relationship. They deliver what we need, are always on-time and are really flexible. A real joy to work with!" — Rok Gregorič, Lead iOS Developer, Benson ### Marina Master: An app worth the 34 years behind it URL: https://350life.com/work/my-marina Client: Marina Master, A Slovenian marina management platform, running in marinas on six continents after more than 34 years in the business. Context: Marina software · Ljubljana, Slovenia Engagement: From 2024, still running Services: product-design, design-systems, app-development Outcomes: - 123 components in the myMarina design system, shipped as Flutter code - iOS + Android the refreshed app, live on both stores since April 2024 (source: App Store and Google Play, verified 8 August 2026) - 2024 and 2026 two refreshes Marina Master announced, the boater app then the platform dashboard (source: marina-master.com news, 17 April 2024 and 10 June 2026) The challenge: IRM has built marina management software in Ljubljana for more than 34 years, and Marina Master now runs in marinas on six continents. The platform is sold to the marina: berths, contracts, invoicing, lifts, movements, the daily operation of a working harbour. myMarina is the other half of it, the app the boat owner holds. That app had not kept up. The version on the stores was published in 2017 and worked the way 2017 apps worked, a mobile web page inside a native wrapper. Its own release notes record the maintenance that kept it upright: a request switched from the desktop page to the mobile one, a fix for the screen bouncing under a touch drag. The screenshots show a login form and a column of blue links. It worked, and boaters used it, and nothing about it said that the software behind it was the software marinas on six continents had chosen. A refresh had to carry two audiences at once. The marina manager sees myMarina during a sale, so it argues for the platform. The boat owner uses it to launch a boat, file an insurance document or pay an invoice, so it has to disappear into the task. And the workflows underneath were not ours to reinvent: they are the platform, and they had to keep the shape the platform already gave them. What we did: - Design a system, not a set of screens. Marina Master carries more than 34 years of accumulated function, so a refresh drawn screen by screen would have drifted apart before it shipped. The work started as a design system rather than a set of layouts: type, colour, spacing, and the components a boater actually meets, which are a request, a boat, a berth, a contract and an invoice. It came to 123 components, and every screen was assembled from them. The point was not a tidier handover. It was that the next thing IRM adds arrives already designed, because the parts it needs exist and already agree with each other. - Build the UI in FlutterFlow, hand back Flutter code. The design was implemented, not handed over as artwork. The UI was built in FlutterFlow, then exported as Flutter and shipped by IRM's own engineers, who wired the Marina Master platform in behind it. That split is the arrangement: 123 components arrive as code that behaves the way it was drawn, and the release stays with the team that knows the platform. One build covered both stores. Marina Master announced the refreshed app on 17 April 2024, and the new iOS listing went live the next day. - Come back for the dashboard the staff live in. Two years later IRM came back for the web application marina staff work in all day, which still looked its age. The brief was a complete design refresh rather than a tidy-up, and it is design: IRM build it. Marina Master announced the first of it on 10 June 2026, describing information tailored to each user's role, whether that is overseeing operations, managing reservations, monitoring finances or tracking marina performance. The rest of the application is still being redesigned. That they came back for the core product, after the app, is the part of this worth pointing at. The non-obvious decision: Build the UI in FlutterFlow and export it as Flutter code, rather than hand over a design file for IRM's engineers to rebuild. There were two obvious routes. A design studio hands over Figma and a specification, the client's engineers rebuild it, and the spacing and states drift over the following months. Or the studio takes the whole build, which puts it between IRM and their own release. Neither fits a platform this old. Marina Master has more than 34 years of workflow behind it, and the people who understand that workflow are inside IRM. So the UI was built rather than drawn, exported as Flutter, and shipped by their team. The 123 components arrive as code that already behaves the way it was designed, and the release, the platform and the domain knowledge all stay where they were. What we built: platforms iOS, Android, Web; stack FlutterFlow (UI build), Flutter (exported, shipped by IRM's engineers), IRM own the Marina Master platform behind the UI; design system 123 components; timeline From 2024 and still running. The refreshed app reached the App Store on 18 April 2024, and the refreshed dashboard was announced on 10 June 2026.. Client review: "They are very devoted to what they do and they put all their efforts to understand what you need. Communication is transparent and responsive." — Vesna Pavlovič, CEO, IRM Ltd. ### Cashews: A no-budgeting money app that took #1 Product of the Day twice URL: https://350life.com/work/cashews Client: Cashews, A personal finance app that replaces budgeting with a single number: what is safe to spend today, this week, and this month. Context: Fintech · Atlanta, Georgia Engagement: 2022 to 2024 Services: product-design, web-design-and-development Outcomes: - #1 twice Product of the Day on Product Hunt, thirteen months apart (source: Product Hunt, 26 June 2022 and 30 July 2023, producthunt.com/products/cashews-for-ios-android/awards) - 100+ screens of mobile app UX and UI designed across iOS and Android - Runner Up Finance Tech Product of the Year, 2023 Golden Kitty Awards (source: Product Hunt, 2023 Golden Kitty Awards) The challenge: Cashews is built on the position that budgets do not work. Rather than asking someone to plan categories in advance, it reads their accounts and answers one question: what is safe to spend today, this week, and this month. That premise is easy to state and hard to draw. Almost every convention available in personal finance design assumes a budget underneath it, so category screens, envelope metaphors, and progress bars filling against a limit were all off the table. The number Cashews shows has no limit behind it. It moves as income is predicted, as recurring bills are detected, and as money is spent, and a person has to trust it enough to act on it while standing in a shop. Getting one figure to read as calm rather than as an alarm was the design problem, and there was no product to copy it from. The scope was the mobile app, the marketing website, and the Webflow build of that website, across 2022 to 2024. It was also among the studio's first product work with a US company, so the interface had to read naturally to an American user connected to American banks. What we did: - Find the number the product is actually about. Cashews had a premise before it had an interface, and no settled answer to what a person should see first. We ran the alternatives as wireframes and clickable prototypes rather than arguing them out. Different ways of expressing what is safe to spend. Different amounts of the underlying calculation made visible. Different weight given to the day, the week, and the month. Several of those were coherent on their own terms. Only one held up once people used it. That round of exploration is why the app opens on a single figure instead of a dashboard, and it is the decision every screen after it depends on. - Design the app around it, at roughly one hundred screens. The single figure is the easy part to draw. The screens go on everything that has to agree with it. Accounts connect and disconnect. Recurring expenses get predicted, then confirmed or corrected. Goals take money out of the spendable figure before the person ever sees it. Transactions arrive from thousands of US banks with inconsistent names and have to be sorted without turning the person into the sorter. We designed the UX and UI across the mobile app, roughly one hundred screens, for iOS and Android. The rule throughout was that no screen could contradict the number on the first one. The moment one does, the product is asking to be checked rather than trusted. - Build the site that has to argue against budgeting. A no-budgeting app has a harder marketing page than a budgeting app, because the reader arrives with the wrong mental model and has to be talked out of it before anything else lands. We designed the website and built it in Webflow, so the team could keep rewriting that argument themselves as they learned which version of it worked. That mattered here more than usual. The product went to Product Hunt twice, in June 2022 and again in July 2023, and the site is what that audience lands on both times. It is still running on the design and the Webflow build we shipped, checked in August 2026. - Stay on it: new features, and onboarding rebuilt. The engagement did not stop at the first launch. Cashews kept shipping through 2023 and 2024, and we kept designing inside it: UX and UI for new features, and a reworked onboarding. Onboarding is where this product is most exposed. Someone has to connect a real bank account before the app can show them anything at all, and what they get back is a number they have not learned to read yet. That work carried the app into its second Product Hunt launch in July 2023, which took first place for the day the same way the first one had. The non-obvious decision: We spent most of the engagement prototyping and testing with potential users, instead of shipping fast and learning in the market. The obvious move is the faster one: get a first version out and let real usage settle the arguments. That works when the product resembles something people already understand. Cashews does not. It asks someone to stop budgeting and trust a single figure instead, so an early launch would have produced churn rather than an answer. Someone who does not trust the number simply leaves, and you learn that it failed without learning which part failed. Testing the models with potential users first meant the version that shipped was one we already had reason to believe would be accepted. The cost was time. What it bought was a first launch that landed. What we built: platforms iOS, Android, Web; stack Webflow; timeline 2022 to 2024. Client review: "350life is an incredible design team. They are thoughtful, strategic, and have an eye for clean and modern design." — Jonathan Manuzak, Founder & CEO, Cashews ### Space Guardian: Satellite collision avoidance, designed to be acted on URL: https://350life.com/work/space-guardian Client: Space Guardian, A satellite collision-avoidance platform that predicts conjunction risk and coordinates the avoidance maneuver between two operators. Context: CASSINI Hackathon winners · Ljubljana, Slovenia Engagement: April 2025 to now Services: product-design, web-design-and-development, design-systems Outcomes: - Ongoing since April 2025 brand, website, web app, and the design system, in one continuous engagement - 50 components and 30 screens in the design system their engineers build from - Web Summit 2025 the web app we designed, shown as the MVP in the Startups area (source: EUSPA, 2025) The challenge: Space Guardian sells automated collision avoidance to satellite operators. The system predicts conjunction risk, calculates the avoidance maneuver, and coordinates it between two operators through a bidding mechanism, so only one satellite has to burn fuel. The company came out of the 8th CASSINI Hackathon, where it placed first in Challenge 3, Orbital Security, in a field of 110 submitted projects. It then had to turn that result into something an operator would trust with hardware in orbit. That meant two audiences and one identity. The website had to make an automated system credible to flight-dynamics engineers who are accountable for equipment they cannot repair, and legible to the agencies and programme reviewers deciding whether the company reaches the next stage. The web app had the narrower and harder job: show an operator why a maneuver is being proposed, what it costs in fuel, and what follows if they decline. One disclosure. The studio holds an operating role at Space Guardian, so this was not an arms-length engagement, and Luka Zlatečan's quote below is a colleague's rather than an outside reference. Read it that way. What we did: - Brand and positioning. Space Guardian had a hackathon result and a technical concept before it had a product to show. We defined the positioning and built the brand it trades under: the identity carried by the website, the product, and the material it takes to agencies and investors. - The website. We designed the site Space Guardian sells from, and their engineers built it. It is live at spaceguardian.eu, though the implementation has since moved onto their own stack. - Web app UX/UI and the design system. We designed the operator-facing web app, the screen where a conjunction warning becomes a decision about a maneuver. Their engineers built it. What went over the wall was a design system rather than a set of flat screens: 50 components across 30 screens, which is the part Luka Zlatečan picked out. The non-obvious decision: Build the operator interface to feel calm and easy, in a category where the software is usually difficult to use. The obvious move was to build what the category builds. Space-tech tooling is dense and expert-facing, and matching it would have signalled technical seriousness to the flight-dynamics engineers who buy it. We went the other way. The screen where an operator approves a collision maneuver is where someone makes a high-consequence call under time pressure, and density works against that. So the product is AI-native by default: the system does the calculation and proposes the maneuver, and the interface has one job, which is to make that proposal legible enough to act on. Space Guardian showed that web app as its MVP in the Startups area at Web Summit 2025. What we built: platforms Web; stack Design only. Space Guardian's engineers own the production stack.; design system 50 components, 30 screens; timeline Started April 2025, ongoing. Client review: "It's crazy how great your design system is. When we got it into our hands it felt like magic for developers…" — Luka Zlatečan, CTO, Indigo Labs ### Keep Technologies: A vehicle security app still running on the interface we handed over URL: https://350life.com/work/keeptech Client: Keep Technologies, A vehicle security device that anchors in the car's cupholder, watches for break-ins, and sends live video to the owner's phone. Context: Atlanta, Georgia Engagement: July 2022, three months Services: product-design, design-systems Outcomes: - 3 months to design the app UI and UX and the components library it ships on - Since Feb 2023 the iOS and Android apps have run on our interface, still updated July 2026 (source: App Store and Google Play, checked 8 August 2026) - a design our team could ship Jonathan Manuzak, CTO, on what the handover was worth to his engineers The challenge: Keep Technologies builds a vehicle security device that anchors into a car's cupholder. It carries a camera, sensors, GPS and radar, arms and disarms itself as the owner comes and goes, and runs alongside a monitoring service where trained staff review footage and contact the police. The app had to hold two states that pull against each other. Most of the time nothing is happening, and the product's job is to be quiet. A person should open it, see that the car is fine, and put the phone away without reading anything. Then something happens, and the same app has to hand them one clear path through it. Getting the quiet state right is what makes the alarm state work, because the person being asked to act under pressure is someone who has never had to look closely at the app before. Our scope was the mobile app UI and UX and the components library it is built from. The build was Keep Technologies' own. What we did: - Design for the quiet state first. Most days the device does its job and nothing happens, so the app's most common task is to say the car is fine and get out of the way. We designed the resting state to be read in a second and to carry none of the language of an alarm. It is the state a person sees hundreds of times, and it sets what an exception will feel like when one finally arrives. - Give the alarm one clear path. When the device does see something, the app stops being ambient. The owner gets a notification, live video of the event, and a decision: silence it, or pass it to the monitoring team who can call the police. We designed that as a path through rather than a set of controls to choose between. Someone reading their phone in a hurry should not have to work out which one matters. - Hand over a components library, not a stack of screens. The interface went across as a components library so Keep Technologies could keep building on it without us. It held. Both apps shipped on it, and the same interface is still in production. The non-obvious decision: Most of the engagement went into the flow that connects the phone to the device, not into the alarm screens. The alarm is the moment the product exists for, so it is the obvious place to spend the design time. It is also the moment a person is least likely to be lost: the app is already shouting, and there is one thing to do. Connecting to the hardware is the opposite. It happens once, in a car park, before the product has earned any trust, and everything after it depends on it working. Someone who cannot pair the device never reaches the alarm screens at all. We put the time where the product could be lost rather than where it looks most dramatic. What we built: platforms iOS, Android; stack Design only; design system Components library covering the mobile app; timeline Three months from July 2022. The app reached the App Store in February 2023 and is still updated, July 2026. Client review: "When the hardware was finished and we needed a mobile app, 350life was the first call. They understood the product fast and delivered a design our team could ship." — Jonathan Manuzak, CTO, Keep Technologies ### Lansia: From a five-year spreadsheet to iOS and Android in one week URL: https://350life.com/work/lansia Client: Lansia, A daily-goals app that turns a long-running personal spreadsheet ritual into a mobile product. Context: In-house product · Slovenia Engagement: Designed 2023, built and shipped May 2026 Services: product-design, app-development Outcomes: - 1 week of evening work to build and submit the app - iOS + Android submitted to both app stores in the same week - 5 years of daily spreadsheet use translated into the product The challenge: Lansia began as a spreadsheet used every day for five years. It already contained the product logic: the goals, the daily record, and the information worth keeping. A mobile design was completed in 2023, but the product stayed unbuilt until May 2026. The practical question was whether that proven workflow could become a finished iOS and Android app without turning a small in-house product into a long development project. We used the existing design and an AI-native build process to implement the app during one week of evening work. Both store submissions were completed within that week. The project became a focused test of how much implementation time could be reduced when the product logic and design were already resolved. What we did: - Translate the spreadsheet into a mobile product. Five years of daily use provided the starting requirements. We mapped the goals, entries, and history into a focused mobile flow, then used the 2023 interface design as the specification for implementation. - Build and submit both apps in one week. The app was implemented through an AI-native production process, with generated work reviewed against the design and product logic in short loops. The build took place during evening sessions over one week, and the iOS and Android submissions were both completed in that window. What we built: platforms iOS, Android, Web; stack Expo, Next.js; timeline Designed 2023; built and published to both stores in one week, May 2026. ### Astropad Workbench: Mac, iPad and iPhone from one design, and a 4.8-star launch URL: https://350life.com/work/astropad-workbench Client: Astropad Workbench, Remote desktop for the AI era. Monitor and control agents running on a headless Mac from anywhere. Context: Minneapolis Engagement: Q4 2025, launched April 2026 Services: product-design, design-systems Outcomes: - 3 platforms Mac, iPad and iPhone, 15 screens designed as one product - 4.8 stars from 148 App Store ratings for the app we designed (source: App Store, checked August 2026) - TechCrunch covered the launch, with MacRumors, 9to5Mac and AppleInsider the same day (source: Sarah Perez, Astropad's Workbench reimagines remote desktop for AI agents, not IT support, TechCrunch, 8 April 2026) The challenge: Remote desktop is a solved category, and that was the problem. The products that exist were built for IT support: someone fixing a machine that belongs to somebody else, at a desk, through a keyboard and a mouse. Workbench is for a different situation. An AI agent is running on a headless Mac mini somewhere, and the person responsible for it wants to see what it is doing from wherever they are. They are reading a log, approving something, or restarting a job that stalled. Often from a phone, in a queue. That put the design on three screens at once, and the three do not agree with each other. What sits in a window on a Mac is the whole canvas on an iPad and a 27-inch desktop squeezed into one hand on an iPhone. One product had to stay legible on all of them without turning into three products. Astropad has shipped Apple-native software since 2013 and owns the streaming codec underneath this one, so whatever we handed over had to be usable by a team with a decade of platform opinions. What we did: - Design one product for three screens. The three apps had to read as one product without pretending the devices are the same. On the Mac, the remote machine sits in a window beside everything else a person is doing. On the iPad, it takes the full canvas and the Apple Pencil becomes a precision cursor. On the iPhone, a 27-inch desktop has to survive being held in one hand, which is the point where panning around stops working and navigation has to become something closer to a map. We designed each surface to its own platform conventions and held the model underneath identical, so moving between them is a change of device rather than a change of product. - Hand a system to an in-house team. Astropad builds its own software and its own streaming codec, so our work ended where their engineering began. What went over was a system rather than a folder of screens: 15 screens across the three platforms, plus the components, states and rules their team needed to build the apps and keep building them once we stepped away. That mattered more than usual here because the product moves quickly. We finished in Q4 2025, Workbench launched in April 2026, and it had reached version 1.2.6 by the end of July. A system keeps up with that. Fixed screens would have been stale by the second release. What we built: platforms macOS, iOS, iPadOS; stack Figma; design system 15 screens across macOS, iPadOS and iOS, on one system; timeline Designed in Q4 2025. Astropad launched Workbench on 8 April 2026.. Client review: "We're really happy with the work. 350life designed our iPhone app, and it looked so good we expanded the project to the Mac app right away. Both have shipped, and the product is getting very good traction. Their designs gave our team a ton to build, but helped us ship a polished product in quick time. We love their work, and we'll be back for more product work." — Matt Ronge, CEO, Astropad ### Concorde: The control app for a luxury motorhome, designed to match the vehicle URL: https://350life.com/work/concorde Client: Concorde, A German manufacturer of luxury motorhomes, building around 400 vehicles a year at Schlüsselfeld-Aschbach since 1985. Context: Premium manufacturer · Schlüsselfeld, Germany Engagement: Q1 2025 Services: product-design Outcomes: - 80 screens of UX and UI design handed to Solvesall to build from - Q1 2025 the one quarter the whole design was delivered in - iOS + Android shipped from our design and live since October 2025 (source: App Store, October 2025) The challenge: Concorde has built motorhomes at Schlüsselfeld-Aschbach since 1985, and builds around 400 a year. The vehicle is the argument: the joinery, the materials, the way one is put together. The app that controls it had to hold the same standard. Concorde Smart Link is the interface to the vehicle's systems. Solvesall built the connected hardware and the production software, and our job was the UX and UI. Two things made that specific. The app controls physical objects, so every control changes something real: heating, power, lighting, water, the state of the battery. It also sits inside a product the buyer chose for how it looks and feels, so it had to read like part of the interior rather than like the diagnostics behind it. Range was the third constraint. Concorde's line-up runs from the Credo on a Fiat Ducato to the Centurion on a Mercedes truck chassis. The screens had to hold across that range and absorb new models as they arrive, rather than being redrawn for each one. What we did: - Make a physical-control app feel native, and feel like the vehicle. Smart Link switches real hardware, so the design was native first. A control that changes the state of the vehicle should behave the way a control the operating system shipped would behave, not like a web page in a wrapper. The surfaces were then drawn to sit with the interior. The materials, the tone and the restraint of a Concorde cabin are what the buyer chose, and the app is the part of that cabin they hold in their hand for the whole trip. - Eighty screens and a component library, handed to Solvesall to build. The design covered the app in full: 80 screens in Figma, delivered as a component library rather than flat artwork, which is how the studio hands over every mobile and web build so the decisions in Figma transfer into code. Solvesall own the connected hardware and the production software, and they shipped it. Concorde Smart Link went live on the App Store and Google Play in October 2025 in English, French and German, and picked up support for new Concorde models in April 2026. The non-obvious decision: Design the app to feel native to the phone and to the vehicle's interior, rather than as a control panel for the systems underneath. The functional read of Smart Link is switching and monitoring: heating, power, lighting, water, battery state, error codes. Designed straight from that description it becomes a utility, and a utility would have been quicker to draw. The reason it is not one is that the app is the only part of a Concorde a buyer holds in their hand, every day of a trip. A screen that looked like machine diagnostics would have been the one cheap-feeling object in a vehicle chosen for the opposite. So the interface was designed to the standard of the interior, and the machine data was arranged to suit that. What we built: platforms iOS, Android; stack Design only. Solvesall own the production stack.; design system Figma component library, structured so the design decisions transfer into code; timeline Designed Q1 2025. Released to both app stores 24 October 2025.. ### Direct4.me: One design system behind six apps, still in use four years later URL: https://350life.com/work/direct4me Client: Direct4.me, A Slovenian company that builds battery-powered parcel lockers and the software that lets any courier deliver to them, including Austrian Post, DPD and DHL. Context: Logistics · Slovenia Engagement: January 2020 to February 2022 Services: product-design, design-systems Outcomes: - 6 apps four mobile and two web, all drawn from one design system - ~1,000 screens across the six apps, counting wireframes and iterations - 4 years the design system has been in use since the engagement ended The challenge: Direct4.me's product is a locker standing on a street, and almost everyone who touches it is doing so because somebody else decided they should. A recipient collects a parcel from a box they did not choose. A courier drops it there on a route they did not plan. An operator watches a network of boxes they will never physically visit. Each of those people needed their own software, and the hardware had already fixed what that software could ask of them. Six products were in flight at once, four mobile apps and two web apps, from January 2020. Designing them one after another was not an option, and designing them side by side meant six versions of the same button, the same locker state, the same parcel status. The design problem sat above the individual apps: what all six had to agree on, before any of them could be drawn. What we did: - Build the shared system before the screens. The first work was not app screens. We built one design system in Figma covering what every app had in common: the components, and the language for a box that can be free, reserved, occupied, or out of service. Direct4.me's mobile development team worked on it with us while it was being set up. That is the reason it survived. A system drawn by designers alone becomes a reference document. One built alongside the engineers who consume it becomes the place the products are actually made from. It was among the first full design systems the studio built. - Draw six products out of it. Four mobile apps and two web apps came out of that system between January 2020 and February 2022. Close to a thousand screens once wireframes and iterations are counted, which is what six products in parallel genuinely costs. The system is what stopped that number becoming six separate arguments about the same locker. It is still in use at Direct4.me four years after the engagement finished, which is a harder test than any of the screens passed. The non-obvious decision: We spent the early part of the engagement building a design system, rather than starting on the six apps that were already waiting. The obvious move with six products in flight is to start drawing screens, because screens are what everyone is waiting for and a system reads as a delay. That is the wrong order here. Six apps describing the same locker will each invent their own word for a box that is reserved, and every one of those inventions has to be reconciled later, in code, across four mobile clients. Building the shared language first meant one decision reached six products instead of six decisions being negotiated. Their mobile development team helped build it, which is why it outlived us. The people who use a design system every day are the ones who keep it alive. What we built: platforms iOS, Android, Web; stack Figma; design system One system in Figma, shared by four mobile apps and two web apps; timeline January 2020 to February 2022. ### Alani: 3,500+ parents registered in the first month URL: https://350life.com/work/alani Client: Alani, A Slovenian webapp that rates children's cartoons on seven measurable stimulation criteria, so a parent can tell how hard a programme works to hold a child's attention. Context: In-house product · Slovenia Engagement: Started May 2026, still shipping Services: product-design, web-design-and-development Outcomes: - 3,500+ parents registered in the first month (source: Tim, 10 August 2026) - 90.9% of registered parents finished onboarding (source: Alani production database, 10 August 2026) - 4.94 / 5 average app rating, from 138 parents (source: Alani production database, 10 August 2026) The challenge: Parents deciding what a three-year-old can watch have two kinds of help available, and neither answers the question they are actually asking. Age ratings say who a cartoon is for, not what it does to a child who is already tired. Recommendation lists are opinion. Alani's premise is that the part parents worry about, how hard a programme works to hold attention, is measurable: how often the scene cuts, how loud and dense the sound is, how saturated the background sits, how fast the animation moves. Seven criteria, drawn from nine peer-reviewed sources. Two things made that hard to build. A score only changes behaviour if a parent trusts it, and trust dies the moment they open a cartoon with no rating, so partial coverage was never an option. And the audience arrives from Instagram, inside Instagram's own in-app browser, where analytics events frequently never fire and a download can open a tab with no way back. The product had to be measurable and usable in the one environment that breaks both. What we did: - Rate every cartoon, not most of them. The catalogue holds 122 cartoons and all 122 carry a score on all seven criteria. There is no backlog of unrated titles, because a rating system with gaps teaches a parent to go and check somewhere else. The method is published rather than asserted: nine peer-reviewed sources, each with a DOI, and where a study states a limitation, that limitation is shown to the parent instead of being buried. Two of the nine carry one. Fifty categories and twenty-one viewing platforms are mapped across the catalogue, so a parent can start from what their child already likes or from what they can actually stream tonight. - Get parents past the sign-up and into a real profile. Onboarding runs four steps and carries a skip button, and 90.9% of registered parents finish it anyway. 85.3% go on to create at least one child profile, and the 3,659 accounts hold 4,560 children between them, so parents are setting the product up for a family rather than for one child. Sign-in splits almost exactly in half between Google and an email with a password, 1,829 against 1,830, which means dropping either route would have cost half the base. Confirmed email addresses sit at 98.1%, which is not what a free sign-up usually looks like. - Write things parents finish, and measure it ourselves. Two full-screen interactive guides run on a typed engine of sixteen screen types checked at compile time, with the content written in TypeScript rather than held in a CMS. More than nine in ten parents who start a guide reach the end, 92.2% on one and 91.7% on the other, and the median parent spends 101 seconds on a screen of the longer one. That is reading, not scrolling. 89.7 hours of it has been measured across the two. The measurement is ours rather than Google's: analytics events often never leave Instagram's in-app browser, so the product records its own. The non-obvious decision: We built the whole product free and grew it to 3,659 parents before putting anything at all behind a payment. The obvious move is to charge early and let revenue tell you whether the thing is wanted. That answers the wrong question here. Alani asks a parent to trust a number enough to change what their child watches, and a payment taken before that trust exists measures price sensitivity rather than belief. So the product shipped free and the work went into being read and answered: guides parents finish, a survey 387 of them completed, 85 content suggestions from parents with all 85 acted on. The payment infrastructure is built and sitting unused. Revenue today is zero euro, which is the intended state rather than a shortfall. What we built: platforms Web; stack Next.js 16, React 19, TypeScript, Tailwind CSS 4; design system 149 React components, 46 of them shared, built without a third-party component library; integrations Supabase, Stripe, Resend, MapLibre GL, Vercel, Google Analytics 4; timeline First commit 1 May 2026, first registration 19 May 2026, still shipping. What is next: Alani is still shipping. A paid tier is the next step, and it goes live only after the free product has been in enough parents' hands to know what is worth charging for. ## How we work On the first call: - You explain the product, where it stands, and what needs to happen next. - We identify the first useful piece of work and say plainly if we are not the right fit. - If there is a sensible way forward, we send a free written scope. Scoping is free. From a clear brief, we write a short plan for the first piece of work, including the deliverable, fixed price, and rough timeline. The scope is the plan; it is not free design or development. If the plan makes sense, the next step is a paid pilot or the agreed engagement. Engagement models: - Audit or review. A paid review of an existing product. We show what should change, why it matters, and what to do first. The recommendations are yours whether or not we continue together. - Paid pilot. A fixed-price piece of real work before a larger engagement. You receive a finished deliverable and both sides learn how the relationship works. - Design partner. Month-to-month product design and development for a live roadmap. Priorities can change without restarting the relationship each time. - Full build. Brand, product design, and software development under one scope and one delivery plan. For fixed-price work, the price stays fixed while the scope stays fixed. Before work begins, we record what is included, what is not, and which decisions we need from you. If the scope changes, we explain the effect on price and timing before any extra work begins. Scoping is free. Paid pilots start around €5,000. Full builds that cover brand, product design, and software development typically start around €25,000. If the available budget does not fit the work, we say so on the first call. Typical timelines: - Free scope: A couple of days from a clear brief - Audit or review: 1 week - Paid pilot: 1–2 weeks - MVP / 0-to-1 build: 4–8 weeks - Full build: 2–4 months - Design partner: Ongoing, month to month Questions: - What kind of work are you best at? Product design and the build that follows it, so the work stays with the same people from Figma to a live site or a shipped app. Most of what we ship is Webflow for marketing sites and Next.js on Vercel for product work, with Supabase or Firebase behind it, TypeScript and Tailwind throughout, and Expo or Swift when it has to be an app. We do the plumbing too: payments through Stripe or PayPal, transactional email, analytics, maps, and the API work that connects a product to whatever a client already runs on, from a CRM to the spreadsheet the operations team will not give up. Work that sits inside that moves fast, because nobody is learning the tools on your budget. - How much does an engagement cost? Paid pilots start around €5,000, and full builds typically start around €25,000. We confirm the price in a free written scope. If the available budget does not fit the work, we say so on the first call. - Do you charge for scoping? No. Scoping is free and produces a short written plan for the first piece of work, including the deliverable, fixed price, and rough timeline. It defines the engagement; it does not begin the design or development. The next step is usually a paid pilot. - How do fixed-price engagements protect us? The agreed price holds while the agreed scope holds. Assumptions, exclusions, and client decisions are set before work begins, and any change is discussed before it affects the budget. - What's the smallest way we can start working with you? Start with a call and a free written scope. The first paid step is usually a pilot: one defined piece of real work before a full build or ongoing partnership. - How fast do you reply to a new enquiry? The same day. You will know quickly whether the work is a fit and what information we need next. - Who owns the work you produce? You do. On completion and payment, the brand, designs, code, design system, and source files are yours. You can continue with us or take the work forward independently. ## Client reviews Reproduced verbatim. 30 reviews from named clients. The studio is rated 4.9 out of 5 on Clutch (https://clutch.co/profile/350life). - "We're really happy with the work. 350life designed our iPhone app, and it looked so good we expanded the project to the Mac app right away. Both have shipped, and the product is getting very good traction. Their designs gave our team a ton to build, but helped us ship a polished product in quick time. We love their work, and we'll be back for more product work." — Matt Ronge, CEO, Astropad - "350life are a dream to work with. They are insanely fast and thorough. We'd often hand off a loose idea at the end of the day and wake up to a polished solution." — Tara Kappel, Co-founder & CPO, RealRoots - "It's crazy how great your design system is. When we got it into our hands it felt like magic for developers…" — Luka Zlatečan, CTO, Indigo Labs - "I work with 350life and I am really happy with the relationship. They deliver what we need, are always on-time and are really flexible. A real joy to work with!" — Rok Gregorič, Lead iOS Developer, Benson - "350life is an incredible design team. They are thoughtful, strategic, and have an eye for clean and modern design." — Jonathan Manuzak, Founder & CEO, Cashews - "I got to know the team through a recommendation from one of my clients…I directly commissioned the team for the next company." — Daniel Pannrucker, CEO, Lama Partners - "Thanks to 350life's work, the app was delivered on time and within budget. User onboarding was quick and painless." — Rok Lenardič, CEO, Indigo Labs - "They are very devoted to what they do and they put all their efforts to understand what you need. Communication is transparent and responsive." — Vesna Pavlovič, CEO, IRM Ltd. - "350life didn't just improve our website. They legitimated our startup. Their UI/UX work was next-level, and they saw onboarding issues before we did." — Rachelle Brempong, Co-founder, Bettershot - "When the hardware was finished and we needed a mobile app, 350life was the first call. They understood the product fast and delivered a design our team could ship." — Jonathan Manuzak, CTO, Keep Technologies - "350Life built landing page for Sellestial in 5 days. We needed speed and we got speed and excellence. One of the best contractor teams I ever worked with. You can't be more responsive than 350life." — Nejc Škoberne, Founder & CEO, Sellestial - "Working with 350life has been a joy. As a very small non-profit with minimal human resources, 350life has been a much needed partner for Spectrum Biobank, helping with UX/UI design and allowing us to concentrate on other organizational operations. The commitment and attention to detail that 350life exhibits is superb." — Bazi, CEO, Spectrum Biobank - "350life was great to work with for our non-profit's website. They were great communicators and very efficient. I would not hesitate to work with them again." — Danny Park, CEO, Spectrum Biobank - "I have had the privilege of working with 350life on a no-code project for our car leasing advertising platform. We went from idea to MVP implementation in two months and that included design, UI/UX, development and implementation. What impressed the most was how committed, fast and responsive the team was. I am very proud of our platform and would recommend 350life for any no-code project." — Niclas Andersson, CEO, Lease Matching - "I needed a website and even though I create a website by myself in the past with Squarespace, I decided to invest in some help for a new project, to allow me more flexibility with design. Working with the team, who set up the page was really nice. I enjoyed the clear communication about the deadlines and potential delays and their managing of last edits with ease. They were open to additional edits, and their willingness to adapt, even when the project seemed complete, made the process really smooth and stress-free. I definitely know who to contact if I ever need programming help again!" — Tjaša Zajc, Digital Health Expert - "The whole 350life team did a great job in building our MVP - from design to launch. We moved extra fast and they helped us implement some of the custom stuff that was needed on top of our Bubble implementation." — Micah Johnson, CTO, Captain - "Working with 350life was an absolute pleasure. The combination of the structured and fast workflow with the incredible creativity and feel for design resulted in magnificent products. We hope to work with you again very soon." — Verena Ortlieb, Co-founder, Terrible Pets - "The implementation of our idea was better than expected. TOP design team and the speed is as you would imagine. The work implementation, structuring and communication is excellent!" — Lars, Mountain Green - "350life is a very hard-working team. Projects are done in time. They are eager to learn and do more than requested." — Tadej Jevsevar, COO, Closer - "I’m super impressed with the speed of learning new things you have been so casually showing off! I mean every word of it! So impressed with your not being afraid of learning new things. I’ll keep pushing and challenging you to see where you can go. :)" — Philipp Berner, CEO, Closer - "I always enjoyed working with 350life. They work quick, professional and precise, with great creativity. They did a great job creating our new company website with a top-notch UX." — Max Gall, CEO, TargetVideo - "I was thrilled with their exceptional responsiveness and efficiency. Despite the truly short deadline, they managed to create stunning designs for both desktop and mobile devices. In addition to the excellent design, they also created a prototype and delivered a presentation. They always listened to the comments. If they thought that something wasn't suitable, they were able to explain it in a clear way and clarify why it would be better to abandon certain elements or why it would be helpful to add something." — Lili Kacicnik, Project Manager, Imovation - "It was a real pleasure to work with 350life. The work went smoothly, any questions or dilemmas were resolved quickly and efficiently. They proved to be very reliable, responsible, fast and professional during the programming of our website and I will be happy to work with them again in the future." — Stanislava Vabsek, CEO, Tehnoloski forum - "As a client, I'm deeply impressed by their exceptional professionalism, creativity, and prompt delivery. Their meticulous attention to detail, innovative ideas, and commitment to deadlines sets them apart from any competition." — Dejan Cencelj, Lead Engineer, MMC, RTV Slovenija - "350life was founded by exceptional individuals with incredible work ethics and knowledge. Team at 350life always exceeds expectations and do all that on time. I'm very impressed with their work and will be happy to have them work their magic on as many projects as possible. The work they have done on Estable is exemplary. They have transformed our digital experience and set-up an iterative beast that keeps growing." — Mark Kalin, Former CEO, Estable - "We came to 350life through a referral and chose them because they understood what we wanted best. They designed our logo and the full visual identity for our official documents, flyers, and business cards. It changed our identity completely, and the result matched what we had in mind. Everything was delivered on time. There is nothing we would change." — Maja Potočnik, CEO, Potočnik in partnerke o.p., d.o.o. - "We brought 350life in for UI and UX design on a custom software project, and they worked as part of our team from day one. They joined our daily meetings, collaborated directly with our developers, and made sure every design decision could actually be built. The end result was a beautiful, visually captivating interface that our own client was genuinely impressed with. Deliverables always came on time, and they went the extra mile when deadlines demanded it. We will definitely hire them again." — Romano Pravdič, CEO, Cloud9 - "I needed a personal website that actually represented my offerings, and 350life built it in Webflow end to end. They kept me in the loop through every phase - what they were doing, when, and what they needed from me. The site launched on time, was thoroughly tested, and the feedback from potential clients and partners has been very positive. My favourite thing about working with them is what kind of people they are: kind, open, transparent, and very detail-oriented." — Amedea Derenda, UX Planning & Consulting - "We brought 350life in for a UI/UX overhaul and strategic product direction, and they delivered a new design system, new game concepts, and a roadmap we could actually scale on. What stood out was how well they understood our space — not just gaming, but where our product fits in the wider ecosystem. On time and on budget, every time. Very responsive, fun to work with, and when small issues came up they were handled immediately." — Joe Kustelski, Head of Product, Chalkline Sports - "I needed a partner with a real affinity for design who could take my input and turn it into seamless websites. We've built three brand sites together since February 2023, with video integration, email capture, and everything in between. Every one has been well-executed, gotten the attention it needed, and brought in new work for our clients. Project management has been exceptional throughout, and they're very easy to work with." — Mina Arko, Brand Consultant, Studio Mina Arko