DEV Community: Oleksandr Sendziuk

Building the Aimgod iPhone app with Claude

Oleksandr Sendziuk — Tue, 13 Oct 2026 15:25:14 +0000

Aimgod is my own product, a calm day planner I have used every day for years. In early October we built its native iPhone app: ten TestFlight builds in four days, written in SwiftUI with Claude Code, tested on my own phone. This is how the work was split, how I direct Claude, what the AI watched for and what went wrong.

Why native, and why now

The Aimgod web app already worked on the phone, and it could be installed from the browser. Then a tester told me something I could not argue with: a planner that lives in a browser tab feels less serious than an app. For something as personal as your day, trust matters. I also noticed that I use Aimgod about 80% of the time on my iPhone.

So we skipped the wrapper and went straight to SwiftUI. A web view inside an app shell would have shipped faster, but it would never feel like it belongs on the phone, and it would not give us widgets, Live Activities in the Dynamic Island or real haptics.

How the work is split

Roughly 70% of the work is still craft: the product idea, the flows, the interface, the motion, the decisions about what goes into the first version and what waits. That part comes from me and from the design system I built in Figma.

The other 30% is where AI changes the economics. Claude Code writes the Swift, keeps the iOS app in sync with the web app, systematizes tokens and specs, writes the tests and uploads the builds. I do not write Swift by hand. I describe, review and test.

The setup is simple. Xcode runs on a Mac mini and is connected to Claude Code through MCP, so Claude can build, run the simulator and read errors itself. The web app is the source of truth: a parity spec lists every screen, state and animation of the mobile web version, and the native app has to match it before it gets anything new.

How I work with Claude day to day

Everything starts from the design system. Either it already exists, or there is a design file, and we turn it into a system first: tokens, type, colours, components, states. Only then do screens and pages get assembled from it, in the app and on the site. That is why the result looks designed and not generated.

I run the work from two places at once. On the computer I watch the build, the simulator or the page. On the phone I give commands by voice, check the result on a real device and send the next correction while Claude is still working on the previous one. Most of my instructions are spoken, short and visual: move this, make that lighter, this animation stops too abruptly.

The corrections are mine, and this is the main difference from AI building something from a prompt. A model can produce a screen that works. It cannot tell that the arrow in a pill looks off centre, that a grey is one step too light for small text, or that a transition feels nervous. That takes a trained eye, and the eye stays with the designer.

Everything else that can be automated, is: builds, uploads to TestFlight, tests, screenshots, guideline checks, the project log. My main tools stay the same as before, Figma, Adobe After Effects and Webflow, with Artlist for AI video backgrounds in my work. Claude sits on top of them and removes the routine.

What Claude watched for

Parity with the web. Every animation has a written curve and duration. Subtasks open in 600 ms on the same curve as on the web, a closing time pill folds to the right, not to the centre. Claude records the web version at 390 px and the simulator, cuts both into frames and compares start, direction, anchor and end state.

Apple's rules before Apple's reviewers. Before we submitted anything, the build was checked against the App Store Review Guidelines that most often cause rejections:

the AI assistant shows a consent screen before the first request, with a link to the privacy policy, and consent can be withdrawn in Settings;
a subscription sold on the website can only appear in the app if it can also be bought there through in app purchase, so version 2.0 ships with free features only and Premium comes with in app purchase in 2.1;
no placeholders for features that are not ready, because reviewers reject "coming soon" screens;
account deletion works inside the app, including revoking the Sign in with Apple token.

Accessibility. An automated audit on every main screen, the largest Dynamic Type size, VoiceOver labels, Reduce Motion, contrast in both themes and tap targets of at least 44 points. A few small grey texts and quiet links failed and were fixed.

Robustness. Airplane mode and sync without duplicates, a slow network, the app killed in the middle of a sync, a day with forty tasks, a time zone change at midnight.

How I test

I am the target user, so I am also tester number one. Every build lands in TestFlight and goes straight onto my iPhone. I plan my real day in it and write down everything that feels wrong, in plain words: "the subtasks jump when I tap fast", "the time blinks when the pill closes". Each note becomes a numbered item in a bug list, gets a regression check and is closed in a named build. Then I install the next build and look at exactly the items that were fixed.

Unit tests did not catch a single one of my animation notes. That is why the frame comparison exists, and why every interaction is run three times in a row: most of the bugs only appeared on the second or third try.

The hard parts

Animations that break on repeat. Subtasks expanded smoothly the first time and jumped every other time when tapped faster than once a second. The cause was a delayed callback fighting the next tap. The fix was one source of truth for open or closed, animated from wherever the rows are at that moment.

A timer nobody understood. The first Live Activity showed a running count in the Dynamic Island, in a serif font. The widget extension cannot see the app's fonts, so it fell back to the system serif. Now the island shows the Aimgod mark, the time left of the current task as a countdown, and a Done button that works without opening the app.

A font detail. Inter, the font of the whole app, keeps a serif on its tabular digit one no matter which font feature you switch on. In the Live Activity timer, where the digits must not jump, we use the system font for numbers only.

Small phones. On the iPhone SE the page scrolled by 110 points in a single frame when subtasks opened. Fine on a Pro, broken on the smallest supported phone. Every check now runs on both sizes.

Voice input. The AI assistant crashed on dictation because the speech permission callback arrived on a background thread, which Swift 6 does not forgive. Caught and fixed before the review build.

What testers asked for first

The first feedback came from the web version. The task list on desktop was set too large for a full day, and people wanted a compact view. It shipped the same day. Two testers said they missed a native app: a web app felt less trustworthy and less smooth than something on the home screen. That became this project. Another tester described how goals should work, and the Goals section was rebuilt around her idea: not a list, but draggable cards connected into a path. The rest were small technical fixes.

The signature details

Some things only make sense on a phone. My favourite is the Live Activity that appears the moment a task starts, with its countdown on the Lock Screen and in the Dynamic Island. Setting a time has its own feel too: the ruler clicks softly under your finger. When you complete a task, a custom haptic pattern plays in sync with the animation: a soft tap when your finger presses the ring, a crisp double tap when the tick lands, and a short rising one when the last task of the day is done. Times in the Dynamic Island and on the Lock Screen follow Apple's format, inside the app they follow ours. Swiping between days moves only the tasks, the header stays still.

Starting the next one

Aimgod began on the web because native development used to cost much more. That is no longer true. Our next product will start on the phone, on iOS and Android, and the web version will follow from the app, not the other way around.

What it took

Four days from an empty Xcode project to a review candidate. A day screen with a time ruler, spheres, subtasks and descriptions, sign in with Apple and Google, sync with the web app in real time, reminders with a Done action, widgets, a Live Activity, an AI assistant with dictation, a weekly productivity dashboard, App Store screenshots and a demo account for the reviewers. Toward the end, Claude was also uploading the builds to TestFlight by itself.

AI did not design this app, and it did not decide what goes into it. It removed the distance between a decision and a working build. That is the part that used to take a team months, and it is the part we now bring to client projects.

Originally published on creayou.com.

Webflow or custom code for a SaaS website

Oleksandr Sendziuk — Tue, 13 Oct 2026 15:18:05 +0000

Most SaaS companies need two things on the web: a marketing site that sells the product and the product itself. They have different owners and different lifecycles, so they rarely belong on the same stack. Here is how we choose for the marketing site.

Start with who edits the site

The first question is not technical. Who will change the pages after launch, and how often?

If a marketing team publishes landing pages, updates pricing, adds customer stories and runs a blog every week, Webflow is usually the right answer. Editors work in a visual interface, the CMS handles collections like posts, case studies and integrations, and nobody waits for a developer to change a headline.

If the site changes a few times a year and the people who change it already work in code, a static site in a Git repository is simpler. Every change is a commit, every commit deploys in seconds, and there is no subscription in between. That is why our own site is plain HTML, while most client sites we build are in Webflow.

The reason is practical. We update our own site by describing changes to an AI, the way we briefed developers for twenty years: long specs with screenshots and arrows, exact wording, and a clear idea of what might break. When something breaks, we see it and fix it at once, because design, AI and development are all our daily work. A client editing a coded site through AI can break it just as easily and not know how to fix it. In Webflow the same client can change a headline by hand, or ask AI for a text update, while classes and components keep the layout safe.

Adding a page is where the difference shows. A client needs to see the structure in front of them: the list of pages, the blog posts, the forms. We hold the structure of our own site in our heads, so we do not need that view. For our own product, Aimgod, we did build a custom admin panel in React, but writing one for a client's marketing site would cost far more than a Webflow plan.

Webflow also takes responsibility for hosting, security and uptime. On our own site we carry that risk ourselves: if something fails, we fix it. A client would have to write to us and wait, and a busy week could mean a week offline. With Webflow, support answers quickly and the platform maintains itself. That is what the monthly plan pays for.

What Webflow does well

Speed to launch. A designed site can go live in days, with hosting, SSL and a CDN included.

A real CMS. Collections, references between them and filtered lists cover most marketing needs: blog, changelog, case studies, team, integrations, job openings.

Editing without risk. Editors change content, the design system stays intact. Classes, components and variables keep pages consistent as the site grows.

Interactions. Scroll and hover animations are built visually, and custom code with GSAP fills the gaps when we need something the interface cannot do.

Where custom code wins

Product level interactivity. A pricing calculator with real logic, a live demo, data from your own API, a WebGL hero. Webflow can embed these, but past a certain size they are easier to build and test as a codebase.

Shared code with the product. When the marketing site and the app should share components, authentication or a design system in code, one stack saves duplicated work.

Full control over performance. Every script and every byte is yours to decide. For most marketing sites Webflow is fast enough; for heavy motion and media, control matters.

No platform limits. Item limits in the CMS, page counts and plan pricing stop being a factor.

The cost nobody puts in the brief

The cost of a website is mostly what happens after launch. Count the hours your team will spend asking for changes, the hours a developer will spend making them and the plan you pay for every month. A Webflow site with a good component system usually wins this comparison for a marketing team. A coded site wins when the team is technical and the site behaves more like software than like a brochure.

The platform question comes up on almost every project

Axis Psychological Services, a psychotherapy practice in Manhattan, came to us asking for a Squarespace site. Squarespace is easy to start with, but it limits motion, layout and custom code. We suggested Webflow instead, and the owner agreed. The site now has custom GSAP animation and a CMS that holds dozens of articles.

How we decide on a project

We ask four questions before choosing:

Who edits the site, and how often?
Does the site need logic or data from the product?
How many content types will it have in a year?
Who maintains it if we are not involved?

For most early and growing SaaS companies the answers point to Webflow for the marketing site and a separate stack for the app. We design both in one system, so the site and the product look like the same company.

If you are choosing for your own product, we are happy to look at it with you. Read more about our Webflow development and SaaS product design.

Originally published on creayou.com.

Rebuilding creayou.com

Oleksandr Sendziuk — Tue, 13 Oct 2026 15:17:10 +0000

Our site was a Webflow export with a heading, a floating video and a contact link. It said who we were in 2023. This is how we rebuilt it, and why it is now plain HTML.

Start from what already works

We did not start from a blank file. The Figma draft had a structure we still liked: logo top left, navigation in the middle, WhatsApp on the right, client login and a message button pinned to the bottom corners. The live site had the typography we liked more. Styrene in capitals, tight tracking, set very large.

So the brief to ourselves was short. Keep the layout from Figma, keep the type and the logo video from the live site, rewrite every word.

Why not Webflow this time

We build most client sites in Webflow and will keep doing it. It is the right tool when a marketing team needs to edit pages without a developer.

Our own site has different needs. The hero runs a custom WebGL shader. The client area will become a dashboard with logins and live data. Nobody but us edits the copy. For that, a static site in a Git repository is simpler: every change is a commit, every commit deploys in about ten seconds, and nothing sits between the code and the browser.

The liquid logo

The logo animation is a short video of our mark rendered as glass. It is the element that took the longest, and it is older than the site. We made it in 2022 with a 3D artist in Blender: a model of the mark, many rounds on the highlights and the refraction, many versions of the motion, and a loop that turns without a visible seam. It still holds up.

On the old site it simply played. Now it runs through a small WebGL program.

The pointer leaves a trail in a low resolution texture. Each frame the trail moves along its own velocity, spreads a little and fades. The video is then drawn through that trail: pixels shift with the flow, colours split slightly at the edges, and where the trail is strongest the mark breaks into droplets. When the pointer stops, the trail fades and the logo pulls itself back together.

The whole effect is about 150 lines with no libraries. If WebGL is unavailable or the visitor prefers reduced motion, the plain video plays instead.

Two themes from one set of tokens

The Figma file already had a dark and a light version, so the colours came straight from its variables: black #1F1F1F, grey #2B2B2B, milk #F5F5F5 and a single neutral grey for secondary text. The site follows the system setting by default and remembers a manual switch.

The logo video was made for a dark background. In the light theme it is inverted and blended so the glass stays visible without a box around it.

Motion with a long tail

Everything moves on the same easing: fast start, slow and soft landing. Headlines reveal line by line from behind a mask. Project images unmask and settle as they scroll into view. The statement under the hero brightens word by word as you read it.

Motion is only worth it if it stays smooth, so the libraries are self hosted, fonts are subset to Latin, and images are resized and served as AVIF or WebP.

What changed

The site finally feels like the studio behind it. The motion is smoother, the effects respond to the visitor, and once the system was in place every new section took hours instead of days. That is the job of a hero section: make a visitor curious enough to stay and look at the work. We will share what it does for enquiries once the numbers are in.

What comes next

Case studies with the full process behind each project, a client area with project status and files, and this journal. We will write about the work as it happens: what we tried, what failed and what shipped.

Originally published on creayou.com.