Norveon Blog

The Velocity Metric That Quietly Broke Our Client

Norveon doo — Tue, 07 Apr 2026 00:00:00 GMT

*No story points were harmed in the making of this post. They were already dead.* A founder we work with pulled us into a meeting last summer. He had a chart on his screen. Story points completed per sprint, going back two years. The line went up and to the right. "Look at this," he said. "We're 40% more productive than we were eighteen months ago. So why does it feel like everything is falling apart?" We looked at the chart. Then we looked at his bug tracker. Then at his last six months of customer churn. The chart was lying. Not on purpose. It was measuring the wrong thing. ## How a number becomes gospel This client started tracking velocity in early 2024. Reasonable thing to do. Most teams running anything Scrum-shaped track it. Their VP of Engineering set it up, presented it at the monthly board meeting, and the board liked it. Number go up, board happy. Once a number gets shown to a board, it stops being a number. It becomes a target. The VP left six months later. The number stayed. His replacement inherited the dashboard, the board expectation, and the unspoken rule that velocity must keep climbing. Here's what nobody on that team would say out loud: every engineer knew exactly how to make the number go up. Estimate generously. Break work into smaller tickets. Skip the cleanup task. Don't volunteer for the gnarly bug because it'll wreck your sprint average. The chart kept climbing. Everyone knew what was happening. Nobody could stop it because the board was watching. ## What we found when we actually looked We spent two days going through their codebase and their tickets. Not the dashboard. The actual work. Test suite took 47 minutes to run. Eighteen months ago it took 9. Nobody had time to fix it because fixing it wasn't worth any story points. Three of their five core services were running on a Node version that hit end of life eight months prior. Upgrade ticket existed. Been in the backlog over a year. Eleven story points. Never picked up. Eleven points spent on three small features moved the chart further than eleven points spent not breaking production. Bug count was up 3x year over year. But bug tickets were getting estimated at one or two points each, while features got estimated at five or eight. So the team was technically "doing more" while shipping a worse product to fewer happy customers. The number on the chart and the health of the product weren't just unrelated. They were moving in opposite directions. ## Why we couldn't just tell them to stop We told the founder: kill the metric. He looked at us like we'd suggested he set the office on fire. "The board sees this number every month. I can't just stop showing it to them. What do I replace it with?" That's the part nobody talks about when they tell you a metric is bad. You can't remove a metric that an executive audience has been trained to expect. You have to replace it with something they trust more. And if you don't have that ready, you're stuck. Same trap we've watched senior engineers fall into when they argue against velocity tracking. They have the right argument. No replacement language. Nothing changes and the number keeps going up while the product keeps getting worse. We had to build the replacement before we could touch the original. ## What we replaced it with We didn't pick one number. We picked four. None of them are perfect. All of them are harder to game than story points. First: time from "bug reported" to "bug closed in production" for the worst 10% of bugs. Not the average. The average lies. The long tail is where the pain lives. If your worst bugs take three months to close, that tells you whether your team is actually shipping quality work. Second: number of changes shipped per week that touched code older than one year. We stole this from a habit we'd built internally. If nobody is touching old code, your team is either avoiding it or doesn't understand it. Both are bad. A healthy team cycles back through old code, making small improvements, deleting things, refactoring as they go. Third: customer-reported issues per active user per month. Not raw bug count. Bug count goes up when you ship more features. Issues per user normalizes for growth. If this number climbs while your user base climbs, you have a problem that velocity will never surface. Fourth: engineer-reported confidence in the codebase. Asked once a month. Single question: "How confident are you in the code you're shipping this month, on a scale of 1 to 5?" Anonymous. We tally it and show the trend. When confidence drops, something is wrong, and it's usually visible weeks before any other metric catches it. We presented these to the board alongside the old velocity chart for three months. Then we dropped velocity. Nobody on the board asked where it went. ## The part where we caught ourselves We're not writing this from some safe outside-expert vantage point. About four months into this client engagement, we noticed something uncomfortable about our own tracking at Norveon. We'd been counting PRs merged per week as a rough pulse on team output. Not for the board, not for anyone external, just for ourselves. Going through the client's history made us look at our own number. Two engineers consistently merged the most PRs. They were also the ones most likely to ship a small fix that broke something else two weeks later. One engineer merged the fewest PRs. He was also the engineer whose code never came back as a bug, who other people trusted to review their work, and who had quietly fixed three of the worst parts of our codebase over the previous year. Our internal number was rewarding the wrong people. Not in any high-stakes way. Nobody was getting fired or promoted based on it. But it shaped how we talked about each other in retros, and the people who deserved more credit were getting less. We killed it. Replaced it with nothing for two months while we figured out what we actually wanted to know. Now we don't track PR count at all. We do a monthly thing where each engineer shares one thing they shipped they're proud of, and one thing in the codebase they wish they'd had time to fix. Lower fidelity. More honest. ## The part that's hard to accept A bad metric is worse than no metric. No metric means you have to use judgment, talk to people, look at the actual work. That's slow and it doesn't fit on a slide. A bad metric means you have a number, the number feels objective, and the number is quietly steering you toward decisions that hurt you. Story points per sprint isn't the only offender. We've seen test coverage percentage do the same thing. Lines of code. Deployment frequency. Even uptime when measured alone. Any number that's easy to game and easy to present will eventually be gamed and presented. The test we use now, before we agree to track anything: if we optimized hard for this number for six months, would the product actually be better? Or would we just be better at producing the number? If we can't answer that honestly, we don't track it. ## Where that client is now They're still running the four metrics. Their bug long-tail dropped about 60% over eight months. Customer-reported issues per user dropped too. The confidence number was the slowest to recover. Took almost a year before it climbed back to where it had been before the velocity-chasing era. That delay tells you something. The trust a team has in its own work takes years to build and gets damaged in months. No metric warns you about this in real time. By the time the dashboard catches it, you've already lost the people who would have fixed it. We're still helping them. They're not done. *Currently helping another client unwind a "deployment frequency" obsession. Ask us in six months whether the new dashboard survived contact with the board.*

How We Hire Engineers

Norveon doo — Tue, 24 Feb 2026 00:00:00 GMT

*No algorithm was whiteboarded in the making of this interview.* We've hired engineers the wrong way more than once. Early Norveon, we did what everyone does. Post a job, collect CVs, send a take-home assignment, do a technical interview, make an offer. Standard process. Felt professional. And then we'd hire someone and realize within a month they weren't the right fit. Or we'd lose a good candidate who took a job somewhere else because we moved too slow. We changed things. Here's what we do now. ## Why We Stopped Sending Take-Home Assignments The candidates we most wanted to hire had the least time to do them. Senior engineers with jobs, families, side projects. They'd get our assignment and weigh it against three others they'd received that week. We also noticed the quality of submissions had nothing to do with job performance. We hired people who turned in polished work and struggled when things got messy. We passed on people whose submissions were rough but who turned out to be excellent when we later crossed paths with them elsewhere. The signal was bad. The cost to candidates was high. We dropped them. ## What We Do Instead Three steps. **A short call.** Thirty minutes. We want to know what the person has built, what they're looking for, and whether there's an obvious mismatch. We're also selling ourselves, a lot of good candidates have options and won't take the next step if they don't like us after thirty minutes. **A working session.** Two hours. We pick something real, an actual bug from our codebase, a slow endpoint we've been meaning to fix, or messy code we want a second opinion on. We work through it together, one of us pairing with the candidate the whole time. We pay for this. It's two hours of someone's time and we're asking them to actually work. **A short reference check and offer.** If the session went well, we move fast. We've lost candidates by going dark for two weeks after a good interview. ## What We're Actually Looking For Not a correct answer. Not a clean solution. We're watching how someone thinks out loud. Do they ask questions before diving in? Do they read the code before changing it? Do they panic when something doesn't work, or do they get methodical? What they do when they hit something they don't know matters most. Good engineers say "I'd normally Google this, mind if I do that?" or "I'm not familiar with this part of the stack, can you give me context?" That tells us more than whether they can reverse a binary tree. ## The Honest Tradeoff This takes more time from our team than sending a take-home assignment. Two hours of someone's calendar, plus prep, plus follow-up. We can't run five of these in a week without it affecting other work. So we're more selective about who we invite to a session, and we spend more time on that first call making sure it makes sense. We're fourteen people. We don't hire often. When we do, getting it right matters more than moving fast. Four engineers hired this way. Three are still with us. One moved cities and we couldn't make remote work for their situation. No dramatic bad-hire stories, but also none of the "looked great on paper, completely different in practice" stories that used to happen. If you're hiring fifty engineers a year, this probably doesn't scale. If you're hiring five, think about whether the time investment is actually that different from reviewing twenty take-home assignments. *Currently running one of these sessions this week. Ask us in a month whether we made an offer.*

How We Run Standup Meetings (It's Not a Daily Scrum)

Norveon doo — Fri, 30 Jan 2026 00:00:00 GMT

*No boards were updated in the making of this meeting.* We don't like working with Agile Frameworks™ like Scrum. We know how to do it. We've led teams working with Scrum and similar methodologies. There's a use case, it can work fine. It's just not what we find the most efficient and pleasant day to day. That said, we love the concept of a daily standup. It's usually the first thing we set up when joining a new client team that doesn't have one. But we don't run standups like daily scrums, so we figured it'd be worth sharing how we actually do it, both internally at Norveon and with the teams we work with. ## How We'd Set This Up Today Here's how we'd explain it to a new team: **The objective is to share interesting things relevant to your team and raise blockers.** What counts as "interesting" will vary depending on context. Use your best judgment and don't hesitate to ask the group if something is interesting to them. **We meet daily at 12:03 before lunch for roughly 15 minutes.** Some days it's 10, others might be 20. Someone keeps time if needed, but we count on everyone to keep things brief. **This is ephemeral.** No boards, no notes. If something critical gets shared, it has to be repeated in writing asynchronously. Email, Slack, whatever. **This is not a reporting meeting.** It's completely fine to share nothing some days. It's even encouraged. You most likely don't do something worth sharing every single day. Yes, we mean it. You'll see us do it. **You will hear updates that don't directly impact you.** Maybe things you don't fully understand. That's normal and by design. Your goal is to pay attention, stay curious, and try to follow what everyone is sharing. Ask questions after. **Every few months, we challenge this format.** That includes cancelling it. What we're proposing is the result of years of small iterations. We like it a lot, but it's not one size fits all. We have to start somewhere. ## What Counts as "Interesting" This part is intentionally vague. What's worth sharing depends on the team and the context. To make it more concrete, here's what we commonly see shared: - **Discoveries.** New tech, new part of the stack, new business opportunity. - **Feature progress.** Something started, a significant milestone, a release, feedback from data. - **Upcoming projects.** Discovery results, research findings, business or legal requirements. - **Reliability problems.** Bugs, outages, post mortems, performance changes. - **Org changes.** New hire, new team. - **Personal events.** Babies, moving apartments. - **Blockers.** Need a review, communication issue, lack of clarity. - **Office news.** New policies, upcoming team building events. ## What This Meeting Is Not It's worth being explicit about what this meeting is not for: **Updating a board.** That's better done asynchronously. **Reporting or tracking tasks.** Same. Especially since not everyone will share an update each day. **Holding people accountable.** People here are professionals and shouldn't need a daily meeting to prove they're making progress. If someone is struggling with that, it needs to be identified and handled elsewhere. **Planning the day.** Do that in smaller, focused groups. Not every day, and team members should be empowered to manage their projects as autonomously as possible. **Forcing people to be present early in the morning.** Yes, we've seen that happen. **Reaching a specific goal.** Since this isn't Scrum, there might not be a sprint or a sprint goal. Reaching goals will be a byproduct of having a cohesive, efficient team. ## Why We Think This Works The main benefits of meeting quickly once a day: **Building empathy.** Before you get a big PR to review, you'll have heard the engineer talk about it. You'll have context on the technical choices, the struggles, the tradeoffs. You'll also know something about their mindset. Are they late? Stressed? You can adjust your communication. Same thing if the PM shares pressure from the business. **Discovering what others are doing.** Over the years we've learned so much about the work of engineers in fields we knew less about, just by listening to them explain daily what they were going through. It's even better when designers and PMs are present and sharing too. **Creating opportunities for discussion.** If you stay locked on your tasks and tickets, you might be more productive short term, but you'll have a very narrow focus. That limits your capacity for impact. **Getting a pulse on the team.** Are people feeling good, productive, positive? Or is everyone struggling? This is especially important for us as a distributed team where you can't count on discussions at the coffee machine. **Building intuition about who works on what.** Hearing someone talk about a topic for months sticks with you. You'll know who to redirect questions to when the time comes. **Improving team dynamics.** Just like regular 1:1s with your manager build a working relationship, regular interaction with teammates is far more effective than a once a quarter workshop. And a small bonus for on site teams: doing it before lunch is a natural way to end the morning and get people eating together. Cheap team building. Surprisingly effective. ## Questions We Always Get We've set this up in many teams over the years. The overall result has been positive. Not 100% of the people got 100% of the value, but the ROI was good enough for us to keep doing it. Here are the questions and pushback that always come up. ### "This is disruptive. I'm better off focused on my code." Since it's every day, you can plan your day around it. We agree it's disruptive. But like regular 1:1s, it's an investment. Might not feel worth it today, but the value becomes visible with regular practice. You might think your role is purely writing code, creating Figma designs, or setting up PRDs. It goes further. Understanding your team is more important than you'd expect. This time will smooth future interactions and save you headaches down the line. ### "We should do this asynchronously." Since the goal is building empathy and connection, doing it in writing feels unproductive. We're not yet convinced that reading a Slack message has the same impact as seeing someone share the same thing verbally. Also, written updates leave a trace and will eventually start feeling like reporting. That's exactly what we're trying to avoid. ### "No one will understand what I'm working on." Sometimes you'll work on something tricky that only you perfectly understand. That's fine. Spend a bit more time explaining the context. You might need to repeat it more often, which is extra work. But it has a double benefit: more people get onboarded onto your topic, and you get better at making deep technical work understandable. Both are worth it. ### "I'm a designer, I don't care what developers are doing." We think this is the wrong way to look at it. Understanding engineers, and having them understand you, is key to your success if you're building software. If you see development as just implementation details, you'll limit what designs you can actually get in front of users. Unless your job is only producing mockups and static assets, you probably don't want that. ### "I'm an engineer, I don't care about non engineering work." Also the wrong approach. It's incredibly helpful to understand more than just tech when building products. It might not be your cup of tea, but hearing about design a couple of minutes a day will help you identify shortcuts, make design debates smoother, and give you tools to challenge solutions that are too complex. We'd encourage you to see your job as more than writing code. Opening up to other fields is a good way to get there, and here you have the chance to learn just by paying attention a few minutes every day. Good deal. ### "We already have too many meetings." If you have many other meetings, we'd rather review and cancel those. The daily standup helps reduce the total number of meetings by preventing problems and misunderstandings. Removing it frees up 15 minutes but will cost many more hours down the line. ### "This isn't Scrum compliant." Correct. It's not a daily scrum and it doesn't have the same objectives. ### "You say it's not reporting, but it really is." We get why it can feel that way. But we don't track what's shared, we don't export it outside the team. You're encouraged to share what's interesting, and that won't always be direct progress on your tasks, which makes this a terrible reporting tool. We'd much rather use our normal ticket tracker to see what's going on. ### "I don't feel confident sharing nothing." If you're new to the team, that's normal. Don't worry. You'll see others do it and it should feel less intimidating over time. ### "Can you really share nothing?" Yes. "Nothing really interesting since last time" works. "Still on the same task, nothing new to share" also works. If someone has nothing to share for several days running, it might signal something. From experience, the reasons are usually one of three: - **They don't think their topics are interesting.** Worth taking a minute to highlight why people might want to hear about a specific part of their work. - **They have a deeper problem.** With the process, the work, the team, the company, or life in general. This needs case by case attention and is usually visible outside the standup too. - **They're stuck and don't feel safe sharing it.** This usually resolves itself once they see others openly sharing blockers. *No framework was harmed in the making of this standup format. Your results may vary.*

Every Startup Team Org We Tried (And Why They All Broke)

Norveon doo — Fri, 28 Nov 2025 00:00:00 GMT

[image1]: /images/blog/2025-11-28.jpg "Every Startup Team Org We Tried" ![Every Startup Team Org We Tried][image1] *There's no perfect team structure, just different ways to be stuck.* Last month a founder asked us: "How should we organize our engineering team?" We laughed. Not because it's a bad question. But because we've watched teams try every answer and they all break eventually. We're 14 people at Norveon. Everyone's a generalist. Works for us. But we've worked with a client who went from 8 engineers to 32 in two years. Got to see every reorganization play out. Here's what actually happened. ## Split by Tech Stack Around 10 people, most teams split by technology. Frontend with frontend. Backend with backend. Mobile together. This client did it in June 2023. 18 engineers total. React web app, Swift and Kotlin mobile apps, Node.js backend. Three teams. Worked for three months. ## Why It Broke Every feature needed all three teams. New onboarding flow? Backend builds APIs, frontend builds forms, mobile updates apps. You're coordinating three teams for one feature. Frontend complained APIs weren't ready. Mobile complained APIs were built for web. Backend had no idea why they were building half these endpoints. Nobody owned any part of the product. Everyone touched everything, so nobody really understood how anything worked. By month four, every standup was "waiting on backend" or "blocked by API changes." ## Squads (Like Spotify) Next try: organize around product areas. Squad A: user management. Squad B: core features. Squad C: billing. Each squad got frontend, backend, and mobile people. Felt way better. Teams owned their area. Could ship without waiting on others. Lasted a year. ## What Killed Squads Nobody worked on technical stuff. React Router upgrade sat in backlog for eight months. Test suite went from 3 minutes to 55 minutes. Whose job was it to fix? Nobody's. The iOS dev in Squad A had nobody to talk to about iOS problems. Squad B picked one state library, Squad C picked a different one. Tech debt piled up. Every squad was measured on features, not code quality. By month 11, three engineers were burned out. ## Adding Chapters So they added chapters. All frontend people in a Frontend Chapter. All backend in Backend Chapter. Chapter leads pushed for 20% time on technical work. Framework updates, knowledge sharing, tech decisions. First two months were great. Updates got done. Tech talks happened. Then the fighting started. ## The Chapter Problem Product managers vs chapter leads. Every sprint. "Why is Alice updating dependencies instead of building features?" "Why did Bob skip sprint planning for a chapter meeting?" They started tracking percentages. Alice: 23% chapter time. Bob: 11%. Everyone hated it. Engineers got pulled two directions. Squad PM wants the feature Friday. Chapter lead wants you in a workshop. Pick one. After six months, people started quitting. ## Platform Team Next: dedicated team for technical work. Moved the backend lead plus two mobile engineers and one frontend engineer. This left the product squads short. Squad A down to one backend engineer. Squad B lost half their mobile capacity. But the fighting stopped. Platform team did tech work. Product squads built features. Except. ## New Problems The backend lead never had time to help their old squad. Squad A fell behind. Their one backend dev was drowning. Mobile engineers kept getting pulled back to product work. Clients complained about iOS and Android being out of sync. The frontend engineer on the platform team wanted to quit after three months. Updating libraries isn't as fun as building features. Worst part: other engineers stopped caring about code quality. "Platform team will fix it" became the excuse for messy code. Platform team started adding more process. Created resentment between the "architects" and "people doing real work." ## Temporary Project Teams Killed the platform team. New plan: temporary teams for big projects. Project Alpha: React upgrade. Three frontend people, two months. Project Beta: rebuild APIs for mobile. Two backend, two mobile, two months. Project Beta took four months instead of two. Wrong scope. Too late to cancel. Project Alpha lost someone after one month. Added a replacement. Onboarding took three weeks. Project ran seven months instead of two. The engineer who stayed all seven months burned out. Quit a month after it finished. Project Beta got canceled at month three. Too complex. Six months later they needed to change something from Project Alpha. Team was gone. Original engineer quit. Nobody knew how it worked. ## Staff Engineers Current setup: promoted two people to staff engineer. One backend, one frontend. They float around. Help where needed. Brought back chapters. 20% time rule. But no tracking this time. Just trust. Been running eight months. Backend staff helped Squad A until they hired someone. Frontend staff led the React update. Staff engineers run monthly "update days." Few people from each squad spend a day updating dependencies and adding tests. Chapters meet every two weeks. Knowledge sharing. Tech decisions. No work assignments. Not perfect. Staff engineers are stretched thin. Hiring them is hard. ## What We Learned Every structure breaks eventually. Tech teams break from coordination overhead. Squads break when tech work gets ignored. Chapters create conflicts. Platform teams disconnect from reality. Project teams miss deadlines. We're 14 people at Norveon. Everyone's a generalist. Works at our size. Wouldn't work at 50. This client is at 32 engineers now. Already seeing cracks in the staff engineer model. ## If You're Doing This Don't copy Spotify. Don't copy Google. Their context isn't yours. Fix what's broken now. Not what might break at 100 people. If coordination is the problem, don't split by tech stack. If tech debt is piling up, don't use pure squads. If people are burning out, maybe skip the chapter model. Try something. Give it six months. Watch for problems. Change when it's clearly broken. Team structure isn't something you solve. Just different tradeoffs at different sizes. *Currently helping another client figure this out. Ask us in six months if it worked.*

Android 16KB Page Sizes: Our Migration Rollercoaster

Norveon doo — Fri, 21 Nov 2025 00:00:00 GMT

*We thought it would take a morning. It took three weeks.* So Google drops this announcement: "Hey everyone, starting November 1st, 2025, your apps need to support 16KB page sizes. Should be easy!" We were migrating [Arheev](https://arheev.com), our intelligent HR platform's mobile app. We read the docs. Seemed straightforward. Update a few build tools, add some config flags, maybe grab a coffee while it builds. Done by lunch, right? Narrator voice: *It was not done by lunch.* ## What Google Wanted (And Why) The basic idea makes sense. Android has been using 4KB memory pages forever, but modern devices with tons of RAM work better with 16KB pages. Google's own data shows some nice improvements: - Apps launch 3% faster when your phone's memory is packed - 4.5% less battery drain during startup - Camera apps run 5–7% faster - Your phone boots 8% quicker Cool benefits! So what's the catch? ## The Real Problem Nobody Warned Us About Here's where it gets spicy. Every native library (.so file) in your app needs to be "aligned" to 16KB boundaries. Think of it like parking: your library needs to fit neatly into 16KB sized parking spaces. If you're writing a pure Java/Kotlin app, you're golden. No native code, no problem. But the [Arheev mobile app](https://arheev.com) is built with React Native. And React Native apps are basically native libraries wrapped in JavaScript wrapped in more native libraries wrapped in existential questions about why we didn't just build separate native apps. When libraries aren't properly aligned, you get: - Apps that refuse to install - Cryptic error messages that tell you nothing - Crashes that only happen on specific devices (usually the ones your boss is testing on) Fun times! ## What Actually Happened: A Timeline ### Day 1: "This Will Be Easy" We updated to Android Gradle Plugin 8.5.1 and NDK r28. The docs said these versions handle 16KB alignment automatically. We added some flags to AndroidManifest.xml: ```xml ``` Build passed. Tests green. High fives all around. Time to celebrate our sub one hour migration! ### Day 3: "Why Isn't This Working?" We spun up an Android 15 emulator with 16KB support enabled. Installed the app. It crashed immediately. Turns out, several libraries hiding in our dependency tree weren't 16KB aligned: - Our audio processing library (libandroidlame.so) - Some image compression thing - A third party SDK we barely remembered adding The error message? "Native module initialization failed." Thanks, Android. Super helpful. We spent two days learning more about ELF alignment than we ever wanted to know. ### Day 5: "Fine, We'll Work Around It" After much Googling (and maybe some coffee fueled Stack Overflow diving), we found the magic flag: `android:extractNativeLibs="true"`. This tells Android to extract libraries when installing the app instead of loading them directly from the APK. It basically sidesteps the alignment requirement entirely. Is it perfect? No. Does it work? Yes. Are we shipping it? Absolutely. **The Good:** - Fixed our crashes instantly - Works with any library, aligned or not - No waiting for third party developers to update their stuff **The Not So Good:** - Apps take a bit longer to install - Uses more storage on the device - Google might phase this out eventually (but that's future us's problem) We're treating this as a temporary fix while we work with library maintainers to get proper 16KB aligned versions. ### Day 7: "Let's Automate This Before We Forget" The last thing we wanted was for someone to run `expo prebuild` and accidentally wipe all our hard earned configurations. So we built an Expo config plugin that handles everything automatically: **AndroidManifest.xml changes:** - Adds the 16KB page size property - Enables the back gesture callback - Sets the extractNativeLibs flag **build.gradle updates:** - Configures NDK ABI filters - Enables multidex support - Sets up release signing **gradle.properties tweaks:** - Build tool settings - React Native new architecture flags - Resource optimization Now when anyone on the team runs prebuild, all these settings just... work. No more "wait, where did that config go?" moments. ## Things We Wish We Knew From Day One ### 1. Upgrade Everything First Don't even think about starting this migration without Android Gradle Plugin 8.5.1+ and NDK r28+. Older versions just don't handle 16KB alignment properly. Update your `android/build.gradle`: ```gradle dependencies { classpath('com.android.tools.build:gradle:8.5.1') } ``` Yes, it's annoying to update build tools. Do it anyway. ### 2. Find Out If You Even Have Native Code Before you panic, figure out if your app actually uses native libraries. The easiest way? Use APK Analyzer in Android Studio: 1. Open Android Studio (any project works) 2. Click **Build > Analyze APK...** 3. Select your APK file 4. Look for a **lib** folder If you see a lib folder with .so files inside, congrats; you have native code to deal with. Check the Alignment column for any warning messages. [image2]: /images/blog/2025-11-21-1.jpg "APK Analyzer menu in Android Studio" ![APK Analyzer menu in Android Studio][image2] No lib folder? You're using pure Java/Kotlin and can probably skip most of this headache. Lucky you. ### 3. Actually Test on a 16KB Emulator Create an Android 15 emulator in AVD Manager and enable "16KB page size" in the advanced settings. Your regular device won't catch these issues because it's still using 4KB pages. Trust us, you don't want to discover alignment problems after shipping to production. ### 4. Hunt Down Your Native Libraries Find all those .so files lurking in your app: ```bash # List all native libraries in your APK unzip -l app-release.apk | grep '\.so$' ``` Or just use APK Analyzer again; it's way easier and has a nice UI. Make a list. Check if any are causing problems. Curse at the ones that are. ### 5. Keep Tabs on Your Dependencies Not every library maintainer has jumped on the 16KB bandwagon yet. Some haven't even heard of it. For React Native: - Check if your Expo SDK version has the fixes - Browse GitHub issues for your native modules - Consider switching libraries if the maintainer went AWOL ### 6. The extractNativeLibs Trick Is Temporary Yeah, `android:extractNativeLibs="true"` fixes everything right now. But treat it like duct tape: it works, but you'll want a proper fix eventually. Keep track of which libraries need it and watch for updates. ## Your Migration Checklist (So You Don't Miss Anything) Here's what you actually need to do: - [ ] Update AGP to 8.5.1+ and NDK to r28+ - [ ] Update Gradle to 8.14+ (might as well) - [ ] Use APK Analyzer to check if you have native libraries - [ ] Add the 16KB page size flags to AndroidManifest.xml - [ ] Set up NDK ABI filters in build.gradle - [ ] Add extractNativeLibs if you're hitting crashes - [ ] Create an Android 15 emulator with 16KB enabled - [ ] Actually test everything (don't just assume it works) - [ ] Make a list of problematic libraries - [ ] Automate your config (future you will thank you) ## The Reality of Cross Platform Development Here's the thing about platform requirements like this: they don't just affect your code. They affect every single library in your dependency tree. When Google says "support 16KB," every native module developer, every SDK provider, every community package needs to comply. And your migration is only done when the slowest library finally catches up. React Native makes this extra fun because you're not just waiting on one ecosystem; you're waiting on native iOS developers, Android developers, and JavaScript developers all coordinating. It's like herding cats, except the cats are also juggling. ## Was It Worth It? After all that work, did we actually see improvements? Yeah, we did: - Less memory fragmentation on newer devices - Slightly faster app starts (hard to measure exactly, but it's there) - No more "your app doesn't work on my phone" bug reports from Android 15 users The extractNativeLibs workaround makes installation a bit slower, but once the app's running, everything feels fine. ### What's Still Not Perfect We're still using `extractNativeLibs="true"` instead of properly aligned libraries. This works, but it's technically a workaround, not a solution. A few dependencies still haven't released 16KB-aligned versions. We're watching their GitHub issues, but some haven't been updated in months. Might need to fork them eventually or find alternatives. And we're not 100% sure how this will perform on actual 16KB devices once they're common. Emulators are one thing, real hardware is another. We'll find out. ## What's Next? More of the same, probably. As Android phones get more powerful, platform requirements will keep cascading through dependency trees. The automation we built for this migration will get used again on the next one. ## The Bottom Line Migrating to 16KB page size support isn't optional if you want to ship on Google Play. And it's definitely more involved than the documentation makes it sound. But once you get through it, you're good. The config mostly runs itself, your app performs better on newer devices, and you have one less deadline to stress about. If you're in the middle of this migration right now and running into weird issues, you're not alone. We've been there. Feel free to reach out if you want to commiserate about library alignment or swap war stories about cryptic Android error messages. ## Useful Links If You're Diving In - [Android 16KB Page Size Docs](https://developer.android.com/guide/practices/page-sizes): The official documentation (which makes it sound way easier than it is) - [Android Gradle Plugin Release Notes](https://developer.android.com/studio/releases/gradle-plugin): For checking what version you need - [Expo Config Plugins Guide](https://docs.expo.dev/config-plugins/introduction/): If you're using Expo and want to automate this mess *Unlike most migrations, this one actually has a deadline. But at least you don't have to do it alone; every React Native developer is going through the same alignment nightmares.* [image1]: /images/blog/2025-11-21.jpg "Android 16KB Page Sizes: Our Migration Rollercoaster" ![Android 16KB Page Sizes: Our Migration Rollercoaster][image1]

When Your Team Gets Too Big: Here's What Actually Worked

Norveon doo — Tue, 24 Jun 2025 00:00:00 GMT

[image1]: /images/blog/2025-06-24.jpg "When Your Team Gets Too Big: Here's What Actually Worked" ![When Your Team Gets Too Big: Here's What Actually Worked][image1] *Six months of failed experiments. This is what we actually found.* Summer 2024. Our team hit fourteen people and everything suddenly felt off. Standups dragged on for 45 minutes. Half the team stared at their screens, clearly not listening. We'd hear about shipped features in retrospect, usually when a client mentioned them. Something had broken, and we weren't sure when. ## When Things Started Going Sideways Those daily check-ins? Pure torture. Marko would talk about his API work while Miloš stared at his phone, clearly thinking about lunch. Meanwhile, Darija was explaining her CSS struggles to a room full of backend developers who couldn't care less. But here's the kicker: while we were all bored out of our minds in meetings, actual work was happening in the shadows. Someone would casually mention they'd just shipped a feature that none of us had heard about. Usually because Stefan from the marketing team had asked for "a quick favor" and our helpful engineers just... did it. ## Our Failed Experiments (All of Them) ### August 2024: The Split We tried splitting into frontend and backend teams. Each team would have their own standup, their own focus. Lasted one sprint. Turns out building Arheev requires both parts talking to each other constantly. Who knew? ### September 2024: Async Updates "Let's do daily Slack updates instead of meetings!" First week, everyone posted detailed updates. Second week, updates got shorter. By week three, we were back to "worked on stuff" and nobody was reading them anyway. ### October 2024: Rotating Team Leads Different person leads standup each week, focusing on their area. Sounded great in theory. In practice: some people ended up in every meeting (because they touched everything), others ghosted entirely. Created more silos, not fewer. ### November 2024: We Almost Gave Up Tried going back to "no formal process, just figure it out." Within two weeks we had the same problems as before. Six months of failing. We were running out of ideas. ## Early 2025: The Accidental Solution We didn't plan this. Someone suggested we try mob programming for one particularly gnarly bug in Arheev. Five people, one screen, working through a problem that touched frontend, backend, and database. We thought it'd be a one-time thing. The bug got fixed. But something else happened: people learned parts of the codebase they'd never touched. The frontend developer understood why the database query was slow. The backend developer saw why the loading state mattered. We started doing it weekly. Not for everything, but for complex features or tough bugs. ## What Actually Changed **Knowledge spread faster.** When everyone sees how something works, you don't end up with one person who's the only one who knows the deployment process. **Fewer "that's not my problem" moments.** Hard to say the frontend isn't your concern when you just helped debug the React rendering issue. **Code reviews got better.** People reviewing code they'd seen built live gave better feedback than people reviewing cold. ## What's Still Broken Let's be honest: we didn't solve everything. **Mob programming doesn't scale to 14 people.** We usually have 4-6 in a session. Everyone else is doing their own work. So we still have coordination problems. **Some people hate it.** Introverts especially. Sitting in a group coding session for two hours can be draining. We haven't figured out how to make it work for everyone. **We still get silos.** Even with generalists, someone ends up being "the person who knows AWS" or "the person who understands the payment flow." Just... less than before. **AI tools help, but they're not magic.** Yeah, you can use Claude to help write SQL when you're normally a frontend dev. But you still need to understand what you're doing. AI makes learning easier, not unnecessary. ## Where We Are Now (November 2025) Standups are down to 15 minutes. We actually talk about what matters instead of giving status reports. Mob programming sessions happen 2-3 times a week. Not everyone participates every time. That's fine. We still have coordination issues. We still have knowledge silos. But they're smaller and less painful than six months ago. ## If You're Dealing With This We wasted six months trying different approaches. Here's what we'd tell past us: **Don't split the team.** Unless you're actually big enough (50+ people), splitting creates more problems than it solves. **Don't force everyone into generalists overnight.** It's a gradual shift. Mob programming or pair programming helps, but it takes months, not weeks. **Accept that some specialization will happen.** That's okay. Just make sure it's not the only person who knows something critical. **Try the 30% rule.** If you're building a product alongside client work, reserve capacity. Otherwise it'll never get built. Your mileage will vary. We're fourteen remote people building an HR platform. Your team, your product, your constraints are different. But if your standups feel like a waste of time, and you keep finding out about work after it's done, you might have the same problems we had. *Unlike your favorite workplace sitcom, this story doesn't have a neat ending. We're still figuring it out as we grow.*

Why Norveon Went Fully Remote (And Why We're Not Going Back)

Norveon doo — Wed, 02 Apr 2025 00:00:00 GMT

*No office politics when there's no office.* Everyone asks us when we're "going back to the office." The question doesn't make sense - we never had one to go back to. Norveon started as a fully remote company in November 2023. Not as a pandemic response, not as a cost-cutting measure, but because we genuinely couldn't figure out why we'd do it differently. We're building software. Our tools are online. Our clients are global. Why would we limit our talent pool to people within commuting distance of Belgrade? Two years later, we're still remote. Here's what actually happened. ## The Things Everyone Warned Us About (That Didn't Happen) ### "You Can't Build Culture Remotely" Wrong. You just build it differently. We do a weekly team call where we actually talk about what we're working on. Not status updates - those go in Slack. Real discussions about technical decisions, problems we're stuck on, things we learned. It's the kind of conversation you'd have in an office kitchen, except nobody has to pretend to like the coffee. Every few months we meet in person for a few days. Not for mandatory "team building" activities, but because after working together for months online, you actually want to meet your teammates. Those meetups are some of the most productive days we have. ### "Communication Will Fall Apart" It got better, actually. In an office, you interrupt someone's deep work to ask a quick question. Remote forces you to think: is this actually urgent, or can it wait? Can I write it clearly in Slack, or do we need a quick call? We've gotten really good at async communication. Detailed Slack threads, screen recordings for bug reports, proper documentation because you can't just tap someone on the shoulder and ask how something works. The flip side: we had to learn this. Early on we'd have week-long Slack threads that should have been a 15-minute call. Now we're better at knowing when to switch mediums. ### "People Will Work Less" Some days, yeah. Some days you have a doctor's appointment, or need to deal with a delivery, or just can't focus and decide to go for a walk instead of pretending to work. But we've also seen the opposite. Someone will push a fix at 11 PM because they're in the zone and want to finish. Another person starts early because that's when they focus best. We track by output, not hours logged. The traditional office pretends everyone is productive from 9-5. Remote work admits that's nonsense and optimizes for when people actually do their best work. ## The Things That Actually Were Problems ### Time Zones Are Still Physics Our team spans several time zones. This is great for coverage - someone's always available if a client needs something. It's terrible for scheduling. We've settled on a 2-hour window (10 AM to 12 PM CET) where everyone's theoretically available for meetings. "Theoretically" because someone's always traveling or has a thing. Scheduling a meeting with the whole team still requires multiple attempts and at least one person joining at a weird hour. ### You Need Better Tools (And Discipline to Use Them) Office work forgives a lot of bad practices. Forgot to document something? Just ask Jim. Not sure about the deployment process? Watch someone do it. Remote punishes that stuff. We had to build proper docs, set up good project management, create clear processes. Not because we're organized people - we're not - but because the alternative was chaos. We use Slack, Linear, Notion, Figma, GitHub, and probably too many other tools. Each one solves a specific problem. Each one also needs to be kept updated or it becomes useless. ### Burnout Is Sneakier In an office, your coworkers notice if you look exhausted. Remote? You can be quietly drowning for weeks before anyone realizes. We don't have a perfect solution for this. We check in with each other, try to watch for signs, encourage time off. But it's still too easy to just... keep working because your workspace is always right there. ## What I'd Tell Someone Starting a Remote Company Do it if your work can actually be done remotely, you're willing to be intentional about communication, and you care about output more than hours logged. If you can handle the messiness of async coordination, it's worth trying. Don't do it if you think it's just cheaper office space, or if you want to monitor what people are doing all day. And if your work genuinely requires constant physical collaboration, remote will fight you at every turn. Same if you're not willing to invest in proper tools and processes, you'll just be in an office with worse communication. ## Would We Ever Get an Office? People ask this. The answer is: probably not. Not because offices are evil or remote is perfect. But because we've built systems that work for us. Our hiring isn't limited by geography. Our team works when they're most productive. We save money on office space and our people save time on commuting. Could we be more productive with an office? Maybe. But we'd also lose the flexibility that lets someone in a different time zone join our team, or allows people to structure their day around their life instead of their commute. The data says most companies are going hybrid. That's probably right for them. For us, fully remote still makes the most sense. ## The Honest Truth Remote work isn't inherently better or worse than office work. It's different, with different tradeoffs. For Norveon, building software with a distributed team, remote works. We've made it work by being deliberate about communication, investing in good tools, and accepting that some things (like scheduling) will always be harder. Two years in, we're still figuring it out. But we're definitely not going back to the office. [image1]: /images/blog/2025-04-02.jpg "Why Norveon Went Fully Remote (And Why We're Not Going Back)" ![Why Norveon Went Fully Remote (And Why We're Not Going Back)][image1]

We Became the Startup We Wanted to Work With

Norveon doo — Sat, 15 Mar 2025 00:00:00 GMT

*No pivot tables were consulted in the making of this product.* Since we started in late 2023, we've been doing client work for startups. Build their MVPs, fix their tech debt, scale their infrastructure. Good work, interesting problems, solid revenue. Then in early 2024 we started building Arheev - our own HR platform - and suddenly we were on the other side of every conversation we'd ever had with startup clients. Turns out, building your own product while running a services company is way harder than we told our clients it would be. ## The Classic Agency Trap Here's how services companies usually think about building products: "We'll use our spare time to build an internal product. When client work is slow, we'll work on it. It'll be great!" We knew this was a trap. We'd seen it fail for other agencies. We told ourselves we'd be different. We were not different. First few months, everyone's excited. People volunteer to work weekends on Arheev. Progress happens fast. We build a working prototype, get some early feedback, everything's great. Then a big client project comes in. "Just two weeks," we tell ourselves. "Then we'll get back to Arheev." Three months later, Arheev hasn't been touched and we've forgotten half the decisions we made. ## What We Changed (That Actually Worked) After the second time this happened, we made a rule: **Arheev gets 30% of our capacity, every week, no matter what.** Not "when we have time." Not "if client work is slow." Just... 30% is reserved for our product. Always. This felt terrifying. What if we had to turn down client work? What if we couldn't meet deadlines? Turns out, constraints force you to be more efficient. We got better at estimating client projects. We stopped saying yes to everything. We hired one more person so we had buffer. And Arheev actually started shipping features consistently. ### The Mobile App Disaster Building Arheev's mobile app, we hit this perfect storm of Android requirements. Google announced the 16KB page size requirement. React Native needed updates. Half our dependencies weren't compatible. The kind of technical debt nightmare we'd normally charge a client premium rates to fix. Except this was our product, our problem, our weekends. We spent three weeks debugging native library alignment issues. No one was paying us for this. We couldn't bill it to anyone. Just had to do it because the alternative was not shipping. This is the part we never really explained to startup clients: sometimes you just have to eat the cost of platform requirements, broken dependencies, and technical changes you didn't cause. ### Actually Listening to Users (The Hard Way) For client work, we have a process. User research, wireframes, prototypes, testing. Very professional. For Arheev? We built what we thought made sense, shipped it, and watched people get confused. One feature we spent three weeks building - this clever automated approval workflow - literally no one used it. They all just manually approved everything because our "clever" system was too complicated to understand. We killed it and built something simpler. Took four hours. People actually use it. Client we probably would have defended our complex solution for weeks. Your own product? You just fix it because there's no one else to blame. ## What This Changed About Client Work Now when a startup client says "we'll handle the mobile deployment ourselves," we don't just nod. We tell them about the three weeks we spent on 16KB page sizes. When they want to build a complex feature because it seems cool, we show them our abandoned approval workflow. When they're trying to fit product work "in between" other priorities, we explain why we had to reserve 30% capacity or Arheev would never ship. We're better at client work because we've lived through the same problems as an internal startup. Not as consultants who read about it. As a team that shipped code at 11 PM because a deployment broke and users were waiting. ## The Uncomfortable Truth Building Arheev made us realize how much easier it is to give advice than to follow it. We told clients "just ship fast and iterate" while spending weeks perfecting Arheev features. We said "focus on core users first" while trying to build every possible feature for every possible HR use case. We recommended "simple wins over complex solutions" while building complex solutions because we thought we knew better. Being on the other side forced us to actually practice what we preached. Or at least try to. ## Where We Are Now Arheev is live. People are using it. We're still building features, fixing bugs, dealing with the reality that software is never "done." We're still doing client work - that's still the majority of our revenue. But we're also running our own product now. It's messy. Some weeks Arheev gets more than 30%. Some weeks less. We're learning as we go. We're a better services company because we went through the same things as our clients. The pressure, the trade-offs, the late nights debugging something that "should have been simple." When we tell a client something is hard, they know we're not just saying that to bill more hours. We've done it ourselves.

How a Small Team Builds Products (Without Losing Our Minds)

Norveon doo — Mon, 03 Mar 2025 00:00:00 GMT

*No corporate buzzwords were harmed in the writing of this post.* We're fourteen people. That's small enough that everyone knows what everyone else is working on, but big enough that you can't just wing it without any process. This size is weird. Too big for "let's all hop on a call and figure it out," too small for departments and managers and formal hierarchies. We've had to figure out how to actually build products at this scale, and honestly, we're still figuring it out. ## What We're Actually Building Right now we're working on two main things: 1. **Arheev** - Our HR platform for growing companies. It's the product we're building for ourselves (and others who need it). 2. **Client projects** - We do custom development work for startups and companies that need technical expertise they don't have in-house. Juggling both is chaos sometimes. We'll be deep in Arheev feature work, then a client project hits a critical bug and half the team pivots. Or we'll plan a client sprint, then realize Arheev needs something urgent for a demo next week. At fourteen people, there's no "separate teams" solution. Everyone touches everything. ## How We Actually Make Decisions In a big company, there are process documents and approval chains. At our size, that's overkill. Instead, we have one rule: **if you think something should be done, prototype it**. Not "schedule a meeting to discuss it." Not "write a proposal for review." Just build a rough version and show it to the team. This sounds chaotic. Sometimes it is. But it also means we move fast and kill bad ideas quickly. Way better than spending two weeks debating something in meetings, then building it and realizing it doesn't work. Marko (our Head of Engineering) came from a place where every change required three levels of approval. He says the first time someone at Norveon told him "just ship it and see what happens," he thought it was a test. It wasn't. We genuinely trust each other to make judgment calls. ## The Friday Failure Report Every Friday, we have a standing meeting where people share what didn't work that week. Not successes. Failures. The Azure deployment that broke production. The feature we built that users hate. The refactor that made performance worse instead of better. The client meeting that went sideways. Early on, people were reluctant to share failures. Now it's the most useful meeting we have. You learn way more from "here's what I broke and how I fixed it" than from "here's what went well." ## When the Junior Developer Was Right Building Arheev, we spent weeks designing the dashboard layout. Multiple iterations, lots of discussion about information hierarchy and user workflows. Then someone newer to the team (who'd been quiet in most meetings) pushed a prototype to staging that threw out our entire navigation approach. Just... completely different. The first reaction was "this breaks all our design patterns." The second reaction, after actually using it, was "wait, this actually works better." We ended up shipping their version. Took about two more weeks to refine it, but the core idea - which came from someone who hadn't been part of all our previous discussions and assumptions - solved the problem better than our "expert" approach. The lesson: sometimes being new means you haven't learned all the wrong patterns yet. ## The Things That Don't Scale (But We Do Anyway) At fourteen people, we can still do things that bigger companies can't: **Everyone reviews everyone's code.** Not just senior developers reviewing juniors. Everyone sees everyone's work. This means code reviews sometimes take longer, but it also means knowledge spreads fast. **We ship directly to production.** No separate deployment team, no change approval board. If you built it and it passed tests, you can deploy it. This terrifies people from bigger companies. We're fine with it. **Everyone talks to clients.** There's no "account management team" shielding developers from users. If you built the feature, you might be the one demoing it or debugging it with the customer. This is inefficient. It's also how you learn what actually matters. ## What Happens When This Doesn't Work Not everything is perfect. Some things at our size just... suck. **Knowledge silos still form.** Even with code reviews and shared projects, one person ends up being "the one who knows how the deployment works" or "the one who understands the payment flow." When they're on vacation, things slow down. **Politics still exist.** Smaller team doesn't mean no disagreements or hurt feelings. We just have fewer places to hide from them. **Growth is weird.** We're too small for specialized roles but too big for everyone to do everything. Do we hire another generalist developer or find a specialized designer? Wrong choice and we're unbalanced for months. We don't have solutions to all of these. We're just aware they exist and trying not to make them worse. ## Why This Matters for Products The way we work directly affects what we build. Arheev (our HR platform) has this feature where you can customize basically everything. Workflows, permissions, data fields, reporting - all configurable. Not because we planned to build "the most flexible HR system" but because that's how we work internally. We hate being forced into rigid processes, so we built a tool that doesn't force users into rigid processes. Could a bigger, more structured team have built something similar? Maybe. But it would have taken more meetings, more planning, more layers of approval. By the time they shipped, the market would have moved. At fourteen people, we can move fast because there's nowhere to hide bad ideas. They get caught in code review, or in Friday's failure meeting, or when someone tries to actually use the feature and realizes it's terrible. ## Where We Are We haven't figured out the perfect way to build products. Nobody has. We're just sharing what works for us at this size, at this stage. Some of this will break as we grow. Some of it already doesn't work as well as it did when we were smaller. We'll adapt, or we won't, and we'll write about that too. Ask us again in a year and the answer might be different.

We Built an HR Platform (Because Spreadsheets Were Killing Us)

Norveon doo — Sat, 22 Feb 2025 00:00:00 GMT

*No spreadsheets were consulted in the making of this announcement.* We built Arheev because our own HR process was a disaster. Fourteen people. Time off tracked in Google Sheets. Employee records in Notion. Documents in Drive. Someone asks "how many vacation days do I have left?" and you have to open three tabs and do math. We tried existing HR platforms. They were either too simple (basically just nicer spreadsheets) or way too complex (enterprise systems designed for 500+ employees that required training to use). So we built something in between. Shipped it in February 2025. Here's what we learned. ## The Actual Problem Our HR "process" looked like this: **Someone requests time off:** 1. Send message in Slack 2. Manager checks the Google Sheet to see if anyone else is off that week 3. Manager manually updates the sheet 4. Someone (hopefully) updates the yearly totals 5. Forget to update it, realize two months later when someone asks why their vacation days are wrong **New employee joins:** 1. Add them to Slack, GitHub, email, Linear, Notion 2. Forget to add them to the vacation sheet 3. Remember three weeks later when they request their first day off 4. Frantically try to remember their start date to calculate accrued time off This is embarrassing to admit as a software company. We literally build systems for other people and couldn't manage our own HR. ## Why We Couldn't Just Buy Something We tried. Really. **BambooHR, Workday, SAP SuccessFactors** - Built for 200+ person companies. We'd be paying for performance review modules, succession planning, compensation management... stuff we don't need. **Gusto, Rippling** - Great for US companies. Less great when your team spans Europe and you don't need payroll (we use accountants for that). **Simple tools like Timetastic** - Basically just makes the spreadsheet prettier. Still disconnected from everything else. We needed something that could grow with us without forcing us to use features we didn't need yet. ## What We Actually Built [image1]: /images/blog/dashboard-interface-2.png "Arheev Dashboard Interface" ![Arheev Dashboard Interface][image1] Version 1.0 has the stuff we needed most urgently: - Time off management: request, approve, track balances. The spreadsheet replacement. - Employee records: basic info, employment details, documents, all in one place. - Departments and positions: org structure without needing org chart software. - Presence tracking: who's working, who's off, who's on vacation. - A "Pulse" dashboard: see what's happening across your team without opening five tabs. That's it. No AI making decisions. No "intelligent automation" that nobody asked for. Just the basics that actually work. ### The One AI Feature (That We Actually Use) We did add one AI-assisted thing: when reviewing time-off requests, the system flags potential conflicts. "Three people from engineering are already off that week" or "This overlaps with the project deadline in Linear." It doesn't auto-approve or auto-reject. Just surfaces information you'd otherwise have to look up manually. Turns out that's way more useful than trying to automate the actual decision. ## What We're Still Building We shipped with the core features working. But there's a lot we haven't built yet: A recruitment module is coming later this year. Maybe. We're still figuring out the right approach. Performance reviews are planned, but honestly we're not sure how to do this without it feeling like bureaucracy. Integrations: right now you can export data. We want proper API integrations with Slack and Linear. It's on the list. The Android app works, but the 16KB page size migration took three weeks and we're still finding edge cases. Version 1.0 solves our immediate problem (getting out of spreadsheet hell). Everything else is roadmap. ## The Migration Was Messier Than Expected We used ourselves as the first real users. Migrated our own HR data from spreadsheets to Arheev in late January 2025. Took two full days. Not because the import was hard, but because our spreadsheets were inconsistent. Some vacation days were in decimals, some in days. Some dates were formatted one way, some another. Realized we'd been calculating time-off accruals wrong for months. If our own data was messy, everyone else's probably is too. So we built import tools that try to handle inconsistencies. They're not perfect, but they're better than expecting clean data. ## Using It For Real We've been running Arheev internally since late January. It's... mostly good. The time-off requests work great. No more spreadsheet confusion. The document storage is fine. Better than Drive folders, but we still forget to upload things. The presence tracking gets ignored sometimes because remote work makes "presence" weird. It just works better than what we had before. For a 1.0, that's enough. ## If You're Also Drowning in Spreadsheets Arheev is live. You can try it if you want. It's designed for teams like ours - 10-50 people, growing, don't need enterprise features yet. Fair warning: it's not polished like the big players. We're still figuring out the UX in some areas. The mobile app works but isn't amazing. We're fixing bugs as people report them. But if you're tracking HR in Google Sheets and it's driving you crazy, Arheev might be worth trying. We built it because we needed it. If you have the same problem, it might work for you too.