DEV Community: Meir Vaknin

How I Made Focusity Easier to Use: A Smarter Connect Screen and One Moodle URL

Meir Vaknin — Sun, 16 Aug 2026 12:47:22 +0000

I build Focusity, a Hebrew study planner. It takes a student's exams and assignment deadlines and builds an actual study schedule around them: when to start preparing, how to split the material, what to do tonight.

All of that depends on knowing the deadlines, and getting them in was the worst part of the product.

The flow I wanted to delete

Open Moodle, find the calendar, click export, download an .ics file, dig it out of your phone's Files app, upload it to Focusity. Then a lecturer moves an exam by a week and you do the whole thing again.

Nobody repeats that. And a planner running on stale deadlines is worse than no planner, because it's confidently wrong about the one thing you're trusting it for.

Moodle does offer a better door. Every user has a private calendar URL:

https://moodle.college.ac.il/calendar/export_execute.php
  ?userid=45146&authtoken=<40 hex chars>&preset_what=all&preset_time=custom

Paste it once. Something re-reads it forever. The student never touches a file again.

That's the whole feature. Most of the work turned out to sit in two places I hadn't planned for: the paste surviving a real phone, and the fetch reaching a college that didn't want to hear from my server.

How this actually gets built

I don't type most of my code. I build Focusity with Claude Code: I decide what gets built and what shape it takes, the agent writes it, and I read the diff. The commits sit in my git history under my name with a Co-Authored-By: Claude Opus 5 trailer, because that's what happened.

That matters for what follows. On the connect screen the agent caught defects I would have shipped without noticing. On the network bug it was no help at all, and why it was no help is most of what I learned.

The screen where you paste it

The feature is one dialog, and close to everyone who opens it is on a phone. That's where most of the work went, and almost none of it was the parser.

The first version had a picker listing the institutions we support. If your college wasn't on the list, there was nothing useful to click. The escape hatch, "my institution isn't listed", was an inline link inside a text-xs paragraph, roughly 16 pixels tall, sitting next to a second one for importing a file manually. Those two links were the entire path forward for exactly the students the feature was built for, at a size you cannot reliably hit with a thumb. Both are now full-width rows with a 44px minimum height, and the picker went from h-10 to h-11 for the same reason.

The picker also used to preselect the single institution we supported. On a phone that reads as a form already filled in with a college that isn't yours, so it stopped doing that.

The two rows at the bottom used to be inline links about 16 pixels tall.

Neither the picker nor the paste field had a real label. The picker leaned on a placeholder option and the paste field on a loose span next to it, which looks fine and tells a screen reader nothing. Both use label and htmlFor now. The two failure banners were visual only, so they carry role="alert", and the decorative icons inside them are hidden from assistive tech. A lock emoji that was doing structural work in the connected panel became a real icon like every other icon in the dialog.

The paste field is type="url" with autocorrect, autocapitalize and spellcheck off. A mobile keyboard will cheerfully capitalize the first letter of a URL you just pasted, and then the connection fails for a reason the student has no way to see.

The escape hatch, opened. The grey note under step one says any Moodle works, not only the ones in the list.

None of it is clever work, but it's the difference between a feature that works and a feature that works for someone who isn't me.

I want to be fair about where the agent helped here. I asked for a review against a UI and accessibility rule set, got five defects back with the tier they fell in, and fixed them in one pass. Left to myself I would have shipped the 16px links, because I'd tested the dialog on a laptop with a mouse, where they're perfectly clickable.

That's the same mistake I'm about to describe making with the server. I got caught for it twice in one day.

Where the request comes from

The original design was the obvious one. A table holds one URL per student. A scheduled function fetches the .ics every night, parses it, and updates tasks.

It keys on the calendar event's UID, so a moved deadline updates the existing task instead of creating a second one, and it only ever touches the name and the date. If a student marked something done, a nightly sync must not undo that.

I tested the pieces. I pulled the real feed with curl and got a valid calendar back. I ran the parser against that real payload and it produced the right course name and the right timestamp out of UTC. Two test harnesses, 23 assertions between them, covering the parser and the URL validator: plain http rejected, hosts off the allowlist rejected, the cloud metadata address 169.254.169.254 rejected, lookalike domains rejected, paths that weren't the export endpoint rejected.

Then I deployed it, connected my own account, and got last_sync_error: moodle_http_403.

The URL in the database was byte for byte what I had tested by hand, so the request itself had to be different. First guess was User-Agent, because college firewalls love rejecting anything that doesn't look like a browser:

curl default UA                  -> 200
no UA at all                     -> 200
Deno-like UA                     -> 200
browser UA                       -> 200

Same token, same path, same headers. The only variable left was where the request came from, so I had the database make the call and also asked it where it thought it was standing:

select
  net.http_get('https://moodle.college.ac.il/calendar/export_execute.php?...'),
  net.http_get('https://ipinfo.io/json');

403  →  <title>403 Forbidden</title> … Transaction ID: 32c9d7c1a891e526…
200  →  { "ip": "18.139.36.225", "city": "Singapore", "org": "Amazon.com, Inc." }

A 403 page with a "Transaction ID" is a firewall, not Moodle. My Supabase project runs in Singapore. The college is in Israel, and it doesn't take visitors from foreign data centers.

Nothing was wrong with my code. My code was standing in the wrong country.

Moving the fetch to the phone

I looked for a server-side answer first, because that's where everything already was. Ask the college to allow our address? Cloud IPs aren't stable or contractual, so that arrangement rots the first time our provider reshuffles and we find out when students complain. Move the server closer? The rule isn't "not Singapore", it's closer to "not a hosting provider", so Frankfurt would very likely get the same treatment, and you can't relocate an existing project anyway. Run a proxy inside the country? Then I'm paying for infrastructure per country, forever, so that one feature works.

Meanwhile my own phone, on cellular, loaded the export page without complaint. Students are exactly who that firewall was built to let in.

So the fetch moved to the phone, and there's one catch worth knowing if you try this. Focusity's mobile app is a WebView, and fetching the file from the JavaScript already running in there doesn't work, because the Moodle export sends no CORS headers whatsoever:

$ curl -sSI -H "Origin: https://app.example.com" "$URL" | grep -i access-control
(nothing)

No Access-Control-Allow-Origin means a browser context won't hand the response to your script. But a native fetch isn't a browser context, and CORS doesn't apply to it. The React Native layer can make the request the WebView can't.

The app already had a bridge for this shape of problem, since native Google sign-in posts a message in and gets an answer injected back, so this became one more message type. Which route runs is decided when the screen opens: device if the app is new enough to answer, server otherwise. An older build simply never replies, times out after four seconds, and falls back.

The part I didn't plan

For a blocked college the server can never use that URL. So why was I storing it there?

On the device route I moved it to the phone's keychain. Written by the device, read by the device, never transmitted to my infrastructure at all. The server route still exists for colleges that don't block us, where an overnight sync beats one that only runs when the app opens. But this was built for the students behind those firewalls, and for them my database no longer holds a live credential to a college account, so it can't leak one.

The host allowlist went the same way. It existed because my server made the request, and an unvalidated host there is a request-forgery primitive. On the device path the phone makes the request, so there's no infrastructure of mine in the path to abuse. The list was buying no security there and costing real students access, so the device path dropped it and kept every structural check. Which is also why the picker can now grow from evidence: a successful connection reports its hostname back, and an institution joins the list because someone actually connected from it.

That's a better design than the one I set out to build, and I didn't reason my way there. A firewall said no, and only then did the stronger option become obvious.

What I'd do differently

The architecture wasn't the mistake. The order of my tests was.

I verified the URL, the token, the parser, the validator, and the dedup logic. I tested the network path from my laptop, which sits on the same kind of connection my users have, and never once from the environment the code would actually run in. That check was a single query away the whole time, and I only ran it after production made me. It's the same shape as the 16px tap targets. Both were invisible from a laptop, because neither was really about the code.

Working with an agent made that easier to fall into. Claude Code will write every test you can describe, and more of them than I would have bothered to write by hand, which is exactly what made me feel covered. But the tests all pointed at the code, because the code is what's in the diff. The Singapore address isn't in the diff. Nothing about the files you're both looking at says this will run from a data center on another continent, at an address someone else's firewall has an opinion about. Deciding that the environment belongs in the test plan isn't a coding task, and nobody was going to do it for me.

So here's the rule I'm keeping: when your code will run somewhere other than your machine, test from that somewhere first. Your laptop is not a staging environment, and the browser on it is not a phone. Each one has a reputation with other people's systems that you never get to see.

I study industrial engineering and management, where a lot of the degree comes down to why systems break at the handoffs, in the places where one component quietly assumes something about another that isn't true. Then I built something that broke at the interface between my server and someone else's firewall, and at the interface between my mouse and somebody's thumb. The theory was fine. I just didn't apply it to my own work until it broke.

What a student gets out of it

You paste one link, once, at the start of the semester. After that, when a lecturer pushes an exam back two weeks, your plan moves with it. You don't re-export anything, and you don't find out in week eleven that you've been preparing against a date that changed in week six.

If your college is one of the ones that blocks us, your login credential also never reaches my servers. It sits on your phone. If you're going to trust a small app with something attached to your degree, that's the shape the trust should have. It happened because a firewall forced my hand, which I'd rather say plainly than dress up as foresight.

I'm a student, and Focusity is what I build when I should probably be studying. The device-side sync is written, tested on a real phone on cellular, and sitting in a TestFlight build. It reaches the App Store when the next release does.

Todo Lists Organize Information. I Built an App That Organizes Time.

Meir Vaknin — Thu, 13 Aug 2026 16:54:45 +0000

It started in a cafeteria

Three of us were sitting in the college cafeteria, complaining about the same thing.

And it wasn't that we couldn't find our information. Every college has an app now. You log in and there it is: your timetable, your exam dates, your grades, the assignment deadlines out of Moodle. All of it, in one place, up to date.

All three of us were still constantly behind.

Because that app tells you an assignment is due on the 14th. It doesn't tell you that Sunday evening is free and that's when you should be writing it. It reports. It doesn't plan. And underneath the whole semester sits the constant low-grade certainty that something is slipping, and you don't know what yet.

We weren't short on information, and we all had todo apps on top of it. The problem was a different one entirely: not one of us could answer this question.

What should I be working on right now, and when do I actually have time for the rest of it?

That question became Focusity.

The pitch, in Hebrew: "Your studies, finally organized."

The distinction that shaped everything

It would have been very easy to build another task manager. Courses, assignments, exams, a nice calendar, done.

But as I said, the information was never the missing piece. The college app already had it, and had it accurately. Even with everything visible in one place, I still didn't know what to do with Tuesday afternoon.

So I drew a line early and never crossed it:

A todo list organizes information.
Focusity organizes time.

Everything downstream came from that. If the product's job is to decide when, then the calendar stops being a display surface and becomes the output. The scheduling engine stops being a feature and becomes the product. And a task the user has to drag onto a free slot by hand is a failure.

That one sentence saved me from about ten features I would otherwise have built.

The MVP call: starting on a platform I knew I'd leave

I started Focusity on Base44, an app-building platform.

I didn't know yet whether the core idea worked, or whether students would even bother importing their schedule. Spending three weeks on auth, database schemas and deploy pipelines before validating any of that would have been optimizing the wrong thing.

What I bought: a working product in days instead of weeks, and fast iteration on flows while the product definition was still moving. What I paid: a ceiling I couldn't see yet.

I'll come back to what happened when I hit it.

Designing before building

Almost every screen in the app has a Figma design behind it. That wasn't process worship, it was arithmetic. Redrawing a screen in Figma costs minutes. Rebuilding it in React costs hours and leaves scar tissue in the codebase. When the UI is dense with information, like a week grid or a dashboard that has to answer "what now?" at a glance, getting the hierarchy wrong is expensive.

There's a branch in my git history called feature/match-figma-pages, and a commit titled "checkpoint before Figma-based calendar/menu QA pass". When the code and the design drifted apart, the code is what moved. That's the difference between having designs and treating the design as the spec.

The feature set, framed around student moments rather than modules.

The four layers

Focusity is four layers stacked, and almost every feature belongs to exactly one of them.

   INTAKE                    MODEL                PLANNING              FOLLOW-UP
   ──────                    ─────                ────────              ─────────
   Moodle ICS  ─┐
   CSV / Excel ─┤                              ┌─ auto-scheduler ─┐
   Exam PDF    ─┼──▶  courses · tasks   ──────▶├─ exam prep       ├──▶  analytics
   Grade PDF   ─┤      exams · time blocks     └─ catch-up board ─┘     grades
   Schedule PDF─┤      grades                                            reminders
   Google Cal  ─┘
                        ▲                                                    │
                        └──────────── velocity feedback ─────────────────────┘

Intake is where most study planners quietly die. Nobody hand-types 22 courses and a semester of class times. So Focusity imports: an ICS feed from Moodle, a CSV or Excel timetable, a PDF exam schedule. Google Calendar connects with two-way sync, so commitments that already live there show up in the plan.

Model is one normalized set of entities, so everything downstream reasons over the same data regardless of where it came from. Planning is the engine, covered in the next section. Follow-up closes the loop: what got done, what slipped, how accurate the estimates were.

Import paths: Moodle ICS, CSV/Excel, exam PDF. Everything routes through a review screen first.

The engine

Given tasks with deadlines and a calendar that's already partly full, place study time. Sounds simple. It isn't, because free time is only the beginning of the constraints.

Hard vs. soft constraints. A class is immovable. So is an exam, and so is a work shift. The only blocks the scheduler may move are the task-study blocks it placed itself on a previous run. Everything else on the calendar, including its own exam-revision blocks, is busy time it plans around. This one rule is what makes re-running it safe: it can never quietly delete something you put there yourself.

Pomodoro splitting. Work is carved into 50-minute focus blocks with 10-minute breaks. Pomodoro isn't magic, but "study for 4 hours" is a lie you tell yourself, and "four 50-minute blocks" is a thing that actually happens.

Eat That Frog. Demanding tasks (high importance, high difficulty, or high energy) claim the earliest slots inside your peak productivity window. You declare that window in settings: Morning, Afternoon, Evening or Night.

That setting had a wrinkle worth mentioning. Originally the planner stopped at 22:00 for everyone, which made Night nearly identical to Evening: a dropdown option that changed nothing. So Night, and only Night, extends the planning window to midnight. If you explicitly told the app you work at night, it should believe you. If you didn't, it should never push a block to 23:30.

Load balancing. A task's blocks spread across the days remaining until its deadline instead of piling into one. A second pass lifts the per-day cap for whatever didn't fit, so nothing is silently dropped. It just lands less ideally.

Personal velocity. My favorite piece. Every session records planned duration and actual duration. After three completed sessions the app computes the ratio and calibrates future estimates, smoothed so one disastrous Tuesday doesn't reset the model.

The effect: if you consistently need 90 minutes for what you estimate at 60, Focusity stops taking your estimates at face value and reserves what you actually need. You don't have to get better at estimating. The system gets better at estimating you.

Priority itself is a plain, boring formula:

export function calcPriorityScore(task, courseBoostMap = {}) {
  const diff = task.difficulty_level || 3;
  const imp  = task.importance_level || 3;
  const deadline = new Date(task.deadline);
  const hoursLeft = Math.max(differenceInHours(deadline, new Date()), 1);
  const urgency = Math.min(10, 100 / hoursLeft);
  const boost = (task.course_id && courseBoostMap[task.course_id]) || 1;
  return Math.round(((diff + imp) / 2) * urgency * boost * 10) / 10;
}

That boost is where grades feed back in: a course whose current grade sits below a set threshold raises the priority of its tasks, scaled by how many credits it carries.

Grades aren't a report card in Focusity. They're an input. The same data drives a "what if I retake this" projection that recomputes your credit-weighted average across up to seven courses at once. The question stops being should I retake this course and becomes which combination moves my average the most, for the least work.

"Most urgent" surfaced up top, today's plan below, one button to reschedule everything.

The plan is the calendar. There is no separate "plan" screen to go read.

Why the engine is not AI

The obvious assumption in 2026 is that an LLM does the scheduling. It doesn't, and that's the most opinionated decision in the app.

The scheduler is deterministic, transparent and fast. You can always see why a block landed where it did: deadline, difficulty, importance, your declared peak hours, the free time you actually had.

An LLM would be worse here on every axis I care about. It's slower, and it's non-deterministic, so re-running the same plan gives a different answer for no reason you can explain. Most importantly, a student who doesn't trust the plan won't follow it, and "the AI decided" is not a reason anybody trusts.

There's also a practical consequence. The planners are pure functions: same inputs, same output, no I/O, no hidden clock. Even "now" is passed in. That's what makes them testable. The exam planner has a standalone harness that hands it a synthetic calendar and asserts the plan that comes back, block by block. You cannot write that test against a language model.

I did build a conversational planning agent at one point. It's still in the codebase, disconnected from navigation, and any message sent to it returns a maintenance notice. That's the honest state of that feature: it doesn't do what its interface promises, so it doesn't get to sit in the nav pretending otherwise. A feature that doesn't work is worse than a feature that doesn't exist, because the first costs you trust and the second costs you nothing.

Trust as a design constraint

Once the product is "an engine makes decisions for you," trust stops being a nice-to-have and becomes the thing you're building.

Every import goes through a review screen. ICS, CSV and PDF imports never write to your calendar directly. You see the parsed rows, fix what's wrong, approve. Parsers fail and university PDFs are chaotic. The answer is to never let a parser have the last word.

The exam planner refuses to lie. When you set up a preparation plan, it checks whether the work genuinely fits in the free time before the exam. If it doesn't, it says so and reports the shortfall in minutes. Silently truncating the plan would have been easy, and that's the version that gets you a bad grade and a user who never comes back.

Nothing missed disappears. Everything you skipped lands on one catch-up board, each item paired with a concrete new slot the engine already found in your real calendar. One tap to reschedule. The failure mode I was designing against is the one I know personally: you fall behind, the backlog goes shapeless, and you stop opening the app.

13 missed items, each with a real free slot already found.

Then I hit the ceiling

About four months in, Base44 stopped being an accelerant.

The breaking points were data access and auth: I needed queries the platform's data layer didn't express, background jobs, and control over the authentication flow rather than the one I was handed. Every workaround was making the codebase worse in a way that would eventually cost more than a migration.

So in a single day in July I moved everything: auth to Supabase, then a schema migration replacing the platform's entities with seven real Postgres tables, then every page and component off the platform's data layer. That schema has since grown to 24 tables across 31 migrations, plus Edge Functions and cron jobs that simply weren't possible before. The migration surfaced an auth-flow deadlock and a fistful of data-layer bugs the platform had been papering over. Painful week. Correct decision.

The takeaway I'd defend in a room: a good MVP decision includes the condition under which you'll abandon it. Base44 did exactly what I chose it for. Staying out of sunk cost would have been the actual mistake, and leaving on schedule was the plan working rather than failing.

Today: React + Vite on the front end, Supabase for Postgres, auth, Edge Functions and cron, Vercel for hosting, a small FastAPI service on Render for PDF parsing, and an Expo shell wrapping the web app for the stores.

Three ways to sign into the same app

Google and Apple sign-in is one line on a roadmap and three implementations in the code: one for the browser, one for the native shell, one for the WebView bridge. Inside a WebView you have no access to the Google session already signed in on the device, so instead of "continue as…" the user gets an empty login form every single time.

And Sign in with Apple isn't a design choice at all: App Store guideline 4.8 requires it once you offer third-party login. Some of your architecture gets written by someone else's policy document.

Where reality pushed back

Rejected by the App Store. Guideline 4.5.4: push notifications can't be on by default. Fair, and fixed by making them opt-in.

Hebrew comes out of PDFs backwards. Right-to-left text arrives reversed from table extraction and has to be reconstructed before anything can be parsed. The service finds the header row by scoring rows against Hebrew keywords and maps columns dynamically. That's what lets one parser handle exports from different institutions without hardcoding column positions.

A native rewrite that didn't ship. I got three phases into a React Native port (scaffold, business logic, UI) before concluding the WebView shell would reach students months sooner at a fraction of the maintenance cost. I deleted the port. Shipping beat purity.

Where it stands

Focusity is live on the App Store. The Android build is in testing with testers, not publicly available yet. It works in any browser, mobile-first, and it's free. There's no paid plan today and no card.

It has real early users. Not many. Their feedback has been positive on the idea and the design, and I want to be precise about what that is and isn't: informal feedback from a small group, not user research, with no usage metrics behind it. What it did was confirm the problem is real and the direction is right. The next step is widening that circle and collecting feedback in a structured way, so prioritization runs on something better than my own judgment.

A productivity score combining estimation accuracy, focus and consistency, along with XP, streaks and streak freezes.

How I actually worked

Semester load meant Focusity moved slowly for months. Since finishing the semester, and while doing reserve duty a week on and a week off, it's had real focused time. The git history shows it honestly: two near-silent months in late spring, then just under 300 commits in July.

The loop stayed the same throughout: define a problem, map the flow, build a version, use it, find what's unclear or broken, improve it. That's not a methodology I read about; it's what happens when you're your own first user.

Every change ships through a branch and a pull request, and every schema change is a numbered, reviewable migration rather than a hand-edit against the database. There are 31 of them so far. That's not ceremony for a solo project. It's what lets me look back and see exactly when a decision was made and what it changed.

And yes, I used AI tooling throughout, including Claude Code, for building, testing, iterating and debugging. What it did was compress the distance between "I know what this should do" and "this works." What it didn't do was decide what the problem was, who it's for, what the engine optimizes for, which features to cut, or when a plan is honest.

There's a symmetry there I only noticed later. I use AI as a development tool and refuse to use it as the product's decision-maker, for the same reason in both directions. The judgment has to be attributable to someone. In the code, that's me. In the app, it's a transparent engine the student can inspect and overrule.

Back to the cafeteria

That cafeteria conversation got one thing exactly right: the problem was never that we didn't know what we had to do. It was that nobody could tell us when.

That's a scheduling problem, not a note-taking problem. Once you see it that way, you build something different.

Focusity: App Store · focusity.co.il

Hebrew-first, RTL from the ground up, free while I grow it. If you're a student, or you build for them, I'd genuinely like to hear what you think.