Norveon Blog

Workalitic Is Now on Android, and It's Built for the Person Holding the Wrench

Norveon doo — Fri, 16 Oct 2026 00:00:00 GMT

*No dashboards were squeezed onto a six-inch screen in the making of this app.* [Workalitic](https://workalitic.com) is our work order and inventory platform for small field service teams. Think HVAC crews, maintenance companies, property managers, electricians. Most of them come to us running the business out of a WhatsApp group and a spreadsheet that exactly one person understands. As of today, the Workalitic app is on [Google Play](https://play.google.com/store/apps/details?id=com.norveon.workalitic&hl=en). iOS is next. ## The web app already worked on phones Workalitic has run in a mobile browser since day one. You can pin it to your home screen and it keeps working when the connection drops. For a manager checking on the day between two meetings, that's plenty. Now picture a technician in a boiler room, gloves on, flashlight in one hand, trying to find the right work order in a full web layout. They'll tell themselves they'll "fill it in later." Later usually means never. That's the bit we cared about. Everything Workalitic does for a manager (reports, costs, stock levels) depends on the person in the field recording what they did. If that takes too many taps, they skip it, and the manager's numbers quietly go wrong. So we didn't port the web app. We asked what a technician actually does on a job, in what order, and built the app around that. ## What's in it The app covers two Workalitic roles. Employees do the work. Viewers need to see what's going on but can't change anything. Admins and managers stay on the web, where planning and dispatch make more sense on a big screen anyway. A technician opens the app and sees their assigned jobs first. Search and filters are there for anything else. On a job they can clock in and out with one tap, and those hours go straight into the reports their manager already reads. They can move a job to In Progress, or mark it Blocked when they're waiting on a part or someone forgot to leave the keys. Blocked was the status we cared most about. Managers see it right away, instead of hearing about it on Friday. Checklists get checked off on site. Comments stay on the job for whoever picks it up next. Materials are tracked the whole way: picked up from the warehouse, used on site, the leftovers returned. Stock updates in real time, which matters more than it sounds. Nobody wants to drive across town for a part that someone else took an hour ago. You can also take before-and-after photos with the camera and attach them to the job, and push notifications tell you when you've been assigned something. You choose which notifications you get. Viewers see the same screens, minus the buttons. We didn't want to show anyone a button that only exists to tell them they're not allowed to press it. ## The boring work The feature list is the easy part to write. Most of the build went into things you only notice when they're broken. Bad signal was the big one. A lot of field work happens in basements and on rooftops, where one bar of signal is a good day. The app knows when it's offline, says so plainly, and doesn't pretend something saved when it didn't. A technician who thinks they logged three valves and didn't is worse off than one who knows to try again. Permissions come from the platform, not from the phone. When a manager changes someone's role on the web, the app follows. If the app and the server each keep their own list of who can do what, sooner or later they disagree, and someone taps a button the server then rejects. Logins stay out of the way. Tokens live in the phone's secure storage and refresh in the background, so a technician on a shared work phone isn't typing a password at 7 AM every day. Apps that make you do that tend to get uninstalled. It's built with Expo and React Native, the same stack we use for client mobile work. That was on purpose. We'd rather recommend a stack we've shipped and supported ourselves, with real users who complain when it breaks. We've written about one Android-specific headache with it in [our notes on the 16 KB page size migration](/en/blog/android-16kb-page-size-migration-challenges). ## Why we bother Workalitic sits alongside [Arheev](https://arheev.com) and [Omnotic](/en/blog/introducing-omnotic-our-pos-hardware-brand) as products we run ourselves. Each one has taught us something we later used on client work, and the clients didn't have to pay for the lesson. This one reminded us that a web app that "works on mobile" can still be a pain for someone standing in a boiler room. Responsive CSS fixes the layout. It doesn't fix the number of taps. ## Try it If you run a field service team, [Workalitic](https://workalitic.com) has a 30-day free trial with every feature and no credit card. Set up a few work orders on the web, then put the [Android app](https://play.google.com/store/apps/details?id=com.norveon.workalitic&hl=en) on your technicians' phones. If you're thinking about building a mobile app of your own, for your team or your customers, [talk to us](/en/#contact). It's what we do. *No technicians were asked to fill in a form twice. That was the whole point.*

Why We Still Invest in Mentorship

Norveon doo — Wed, 23 Sep 2026 00:00:00 GMT

*No junior engineer was assigned a reading list in the making of this post.* One of our engineers had been fighting the same category of bug for months. Flaky integration tests, always a different test, always some timing thing. They'd gotten very good at fixing them. Fast, and the PR description always explained exactly what had gone wrong. Then a senior sat in on a screenshare for twenty minutes and said: you're not fixing flaky tests, you're fixing a shared fixture that everything writes to. That was the whole intervention: twenty minutes, one sentence, and a problem that had been quietly taxing a sprint's worth of attention every month stopped existing. The engineer could have asked a model about any one of those failures and gotten a good answer. They did, often, and the answers were correct. What nobody was going to volunteer was that the answers were all to the wrong question, because nobody else was watching the pattern across months. ## Being productive and getting better are different things This is the distinction that got blurry over the last two years, and we think blurring it is expensive. An engineer with good tooling can ship real work today without understanding much of why it works. We don't mean that as a criticism. It's what tools are for. But shipping and growing have quietly decoupled, and a team can look healthy on output for quite a while before anyone notices that nobody's judgment is developing. We see it most clearly in reviews. Someone's code is fine. It's been fine for a year. It's also been the same kind of fine, solving the same shape of problem the same way, and when the shape changes they're stuck in a way that their PR history would never have predicted. Output tells you what someone produced. It tells you almost nothing about what they could produce next quarter. ## Code review is not mentorship We believed it was for longer than we should have, partly because it's convenient to believe. Review is already on the calendar. It already involves a senior looking at a junior's work. Close enough, surely. It isn't, for a structural reason: review sees the artifact, not the reasoning that produced it. By the time a PR exists, the interesting decisions are gone. The three approaches that got discarded in the first hour, the wrong mental model that made approach two look appealing, the assumption about how the database behaves that turned out to be false but didn't happen to break anything this time. None of that is in the diff. You can only review what survived. And the flawed reasoning is the thing worth catching, because it will produce a different bug next month in a file nobody thought to connect. We still review everything, we just stopped expecting it to do a job it was never shaped for. ## You can't ask about a blind spot The obvious objection to all of this in 2026 is that a model is available at 2am, never tired, never condescending, and knows more about your framework than anyone on your team. All true. We use these tools constantly. They have made the question-shaped part of learning close to free, and that's a genuine gain. The engineer who used to wait until Monday to ask something now just asks. But every one of those interactions starts with you knowing what to ask. That's the constraint, and it's not a temporary one. A model can challenge an assumption you put in front of it. It cannot walk past your desk, metaphorically, and notice that you've been doing something strange for six months. It has no view of you across time. Each conversation starts from nothing. The things that actually hold engineers back are rarely knowledge gaps. They're habits. Reaching for the same abstraction every time. Chronically underestimating a certain kind of task. Going quiet when stuck instead of asking, which is a much bigger deal on a [fully remote team](/en/blog/why-we-went-fully-remote) where nobody can see you go quiet. None of those are questions, which is exactly the problem. Somebody else has to notice them for you. ## Everyone else figured this out already It's a little odd that software treats coaching as a remedial intervention. No serious athlete stops having a coach after they get good. Musicians who have been performing for thirty years still take lessons. In both cases the coach is frequently less capable than the person they're coaching, and that's fine, because the coach is there to see from outside. Software is the outlier here. We've built a culture where asking for a mentor reads as an admission, and where seniority is quietly assumed to mean you've graduated from needing one. Our most experienced people have been writing production code since 1997, and they still get more out of an hour of someone watching them work than from most conferences. Inside the team that's mostly unremarkable now. It took a while to get there. ## Software's feedback is badly calibrated Part of why this matters more in our field than in most: the delay between a decision and its consequence is wildly inconsistent. Get the syntax wrong and you know in under a second. Get the architecture wrong and it compiles, passes the tests, sails through review, ships, and then costs you a quarter eighteen months later when a requirement arrives that the model can't absorb. By then whoever made the call has forgotten making it, and the connection between cause and effect is unrecoverable. You cannot learn from feedback on that timescale. Nobody can. The loop is too long and too noisy. A mentor shortens it artificially. They've already lived through the eighteen months, several times, and can tell you on Tuesday what you'd otherwise find out in 2028. Most of that is exposure somebody else already paid for, and it's about the most useful thing an experienced engineer has to hand over. We wrote about [a client's velocity metric that broke their team](/en/blog/the-velocity-metric-that-quietly-broke-our-client), and that's the same failure at the organizational level. The consequence arrived far too late to be connected to the decision. ## Friction is load-bearing One thing we're careful about, because it's easy to get wrong in the opposite direction. The instinct with a struggling engineer is to remove the obstacle. It's faster, it's kind, and it's usually the wrong move, because the struggle is where the learning lives. Handing someone the answer produces a working feature and no new capability. So the useful version is narrower than it sounds. Let people get stuck. Just don't let them stay stuck on something that has no lesson in it, or stuck in a direction that's structurally hopeless. The judgment call is whether the friction is teaching anything, and getting that call right is most of the skill. This is also the failure mode of an always-available assistant. It removes friction indiscriminately. It cannot tell the difference between a struggle worth having and a yak worth shaving, because it doesn't know what you're supposed to be learning this year. ## Does everyone need this? No, and we'd rather say so than sell it. If you're just starting out, a good book and a community will take you further than a mentor will, because the fundamentals are well-documented and you don't yet have the specific gaps that make one-on-one time worth it. If you have a bounded question, read the docs. If you want a code review, get a code review. Mentorship earns its cost when the return is a multiple of the time invested, and that's usually true in exactly one situation: you're doing this professionally, you're past the beginner stage, and you've hit a ceiling you can't see the shape of. That last part is the tell. When you can name what you're missing, go learn it. When you can't, and you've been stuck at the same level for a year, that's when someone watching from outside pays for itself in a single afternoon. ## What we actually do We've kept this deliberately unstructured, because every formal mentorship program we've seen from the inside became a calendar obligation within two quarters. What exists at Norveon: nobody works alone on anything for very long, pairing happens by default rather than by request, and [our standup](/en/blog/how-we-run-standup-meetings) is explicitly not a status meeting, which means the hesitation in someone's voice is audible. That hesitation is usually the signal that someone's stuck in a way they haven't worded yet. The other half is that we [hire for it](/en/blog/how-we-hire-engineers). We're 14 people. One person who treats questions as an interruption can shut down learning across the whole team, and no program survives that. Nothing in a process document outranks whether the most senior person in the room is visibly still learning. We're not entirely sure this holds, by the way. Keeping it informal means the people who ask get mentored and the quiet ones can go a long time without anyone noticing. Someone raises this roughly twice a year and we've never landed on a fix that doesn't turn into the calendar obligation we were avoiding. At 14 people you can paper over it by knowing everyone. We assume that stops working at some size and we don't know which one. Working on [Arheev](/en/#products) turned out to be where we noticed most of this. When the same team ships the same product for a long stretch, you can see exactly who is getting better and who has plateaued while remaining perfectly productive. Those two look identical on a sprint board. Two years out they don't look alike at all. *No mentor was assigned via ticket. A few conversations ran long.*

One Product, Many Suppliers, Many Channels

Norveon doo — Tue, 01 Sep 2026 00:00:00 GMT

*No spreadsheet was harmed. Several were retired.* Almost every ecommerce system assumes a product has a price. It's such a reasonable assumption that you don't notice you've made it until you meet a business where it's false. Distribution is one of those businesses. You buy the same item from several distributors, each quoting a different cost with different stock. You sell it through other people's storefronts, each wanting a different price and taking a different cut. The product in the middle is one product. Almost nothing attached to it is singular. We spent this year building a system for that shape, for [Inovio doo](/en/case-studies/inovio-hub). Here's what we'd carry into the next one. ## Both directions are adapters Importing from a supplier and exporting to a channel look like different problems. Inbound is XML from one distributor, a CSV drop from another, a REST API from a third. Outbound is marketplaces that each want their own feed format. Structurally they're identical: something external and changeable, sitting on one side of a boundary you control. So every supplier is an adapter producing offers in one internal shape, and every channel is an adapter consuming the catalog in one internal shape. What varies lives in the adapter. What matters lives in the middle. The payoff is what the next one costs. Adding a supplier means writing an adapter, without touching pricing, stock or any other channel. One rule earned its place early: nothing gets silently dropped at a boundary. A row we can't match doesn't disappear into a log line. If it's active and it has a name it becomes a draft product waiting for a person, tagged with the reason it couldn't be placed, and matched by its code on every later run instead of being created again as a duplicate. Inbound feeds sit behind a circuit breaker too, so a supplier having a bad morning gets backed off and reported rather than retried into the ground. ## Compute the price once The rule we'd most want to keep: nothing recomputes a price at export time. That isn't what we inherited. Some channels applied their own margin formula on the way out, so the price in the system and the price on the marketplace were different numbers, and the real one existed only inside the code that generated that particular feed. Ask why an item is cheaper on one marketplace and nobody can answer without reading two feed generators. Now pricing is one engine that knows about per-channel terms and produces the number that actually gets published. Export formats. It does not calculate. Stock works the same way, derived in exactly one function from internal and supplier availability. A second implementation is treated as a bug, because the second one is always the one that drifts. ## Your identifiers belong to other people This is the one that cost the most thought, and the one we'd flag to anyone replacing a catalog. When you migrate, you naturally want clean new internal identifiers. The problem is that every marketplace you sell through already knows your products by the identifier the old system generated. That code lives in their database, attached to your listing's history and its ranking. Change it and you're relisting from scratch, throwing away everything those listings earned. So a migrated product keeps answering to its old code on channels that already knew it, while carrying a new internal identifier for everything else. Unglamorous modeling, and the difference between a migration nobody outside the company notices and one that costs a quarter of marketplace performance. The general version: when you replace a system, its identifiers may be the part other people depend on, and they didn't agree to your migration. ## The back office is not a website Fairly early on we stopped treating the admin interface like a website. Operators here do one thing for most of the day: scan long tables of products, offers and prices, hunting for the row that's wrong. Every instinct you've picked up from building marketing sites works against you. Generous whitespace means fewer rows on screen. A comfortable 16px body means fewer rows on screen. Every bit of breathing room you add costs the user the exact thing they came for. So body text is 12px, spacing is deliberately tight, and rows per screen is the number we optimize. We went as far as turning on the font's alternate glyph set for l, 1 and I, because in a narrow column of SKUs at 12px those three are genuinely hard to tell apart, and misreading a code costs somebody ten minutes and a wrong edit. In a design review it reads as cramped, and we've had that conversation more than once, mostly with each other. Nobody who uses it all day has asked us to loosen it. ## AI proposes, a person decides A catalog built from many distributors is uneven by nature. One supplier sends a full description and clean attributes. The next sends a name, a price, and a photo. Both have to be good enough for a marketplace that rejects a listing over a missing dimension. Closing that gap used to be a people problem, which capped catalog quality at however many hours you could spend on it. So we treat AI as an enrichment service over the dataset, in the same family as any other data provider the platform calls: it takes the product we have, fills in the fields the feeds didn't supply, and hands them back. It proposes a category with a confidence score, completes missing attributes, derives the logistics fields, and reads the product's images when the text alone isn't enough to tell. Anyone can call an AI endpoint. The interesting part is where its output is allowed to land. Nothing the service returns is written onto the product. It's stored beside it as a pending suggestion, and an operator accepts or rejects it against the current value. Acceptance is recorded, so a year later you can still tell which fields a person entered and which a person approved. That property matters more than it sounds. Someone catches the obvious howler. The dangerous failure is a plausible but wrong value written silently into a record, which then spreads to every channel and looks exactly like data a human entered. Once you can't tell which is which, you can't audit it, and you can't clean it up without rechecking everything. We allowed one exception: physical dimensions fill empty logistics fields directly, because there's no editorial judgment in the width of a box, and the provenance is still recorded. The honest cost of all this is a review queue. Somebody has to sit with it, and on a bad week it's a real chunk of an operator's day. You could argue we're being too careful, and plenty of teams would just write the values in and fix complaints later. We'd rather have the queue than a catalog we can't vouch for, but it is a trade and we made it deliberately. ## What generalizes Treat every external party as an adapter, inbound and outbound both. Derive each meaningful number in exactly one place. Before migrating anything, ask which of your identifiers other people have already written down. And where AI enriches your data: keep what the service proposes separate from what your system believes, with the transition between them recorded, or you end up with a dataset you can never audit. None of this is clever, but it's what decides whether adding the next supplier costs you an afternoon or a quarter, and whether AI enrichment leaves you with a better dataset or a slow-motion data quality incident. *Many channels. One price engine. And an enrichment service that never gets the last word.*

What Engineering Leadership Actually Looks Like on a Team of 14

Norveon doo — Wed, 29 Jul 2026 00:00:00 GMT

*No org chart was redrawn in the making of this post.* There's a piece from the Software Leads newsletter on [engineering leaders' day-to-day activities](https://softwareleads.substack.com/p/engineering-leaders-day-to-day-activities) that we passed around internally. Its argument is that management work looks invisible next to writing code, but it isn't formless. It's a cycle of six activities that repeats all day: gathering information, sharing it, making decisions, influencing decisions you don't own, setting direction, and planning. We recognized every one of them. We also realized we do almost none of them the way the framework implicitly assumes, because that framework is written for a manager inside a larger org. We're 14 engineers and designers, fully remote since 2023, and we ship our own products alongside client work. So here are the same six activities, and what each actually looks like at our size. Some of them get easier. A couple get harder in ways nobody warns you about. ## Gathering information The article makes a point we'd underline twice: everything downstream depends on the quality of what you collect first. Bad inputs, bad decisions, and you won't find out for weeks. At a larger company this is a real job. You're pulling context from skip-levels, dashboards, incident reviews, and three teams who each describe the same problem differently. At our size, most of it arrives on its own. We've written about [how we run standups](/en/blog/how-we-run-standup-meetings), and that meeting is doing more work here than anything else we do. Fifteen minutes a day where people share what's interesting rather than report status, and you end up with a running picture of the team that no dashboard would give you. You hear the hesitation before someone says "it's fine." The catch is that this only works because we're small enough for one room. It doesn't scale, and we know it. We've watched clients hit the size where informal context stops arriving and nobody notices for a quarter, because the absence of information doesn't announce itself. If your standup has 25 people in it, you no longer have this. You have a status meeting wearing a standup's clothes. ## Sharing information This is where being small stops helping and starts actively lying to you. When everyone hears everything, you assume everyone knows everything. They don't. Someone was on holiday. Someone was heads-down in a migration for two weeks. Someone joined last month and has no idea that the thing you all call "the old billing thing" was a deliberate decision and not an accident. Our rule from the standup post covers this: it's ephemeral, and anything critical has to be repeated in writing. That rule exists because we got it wrong. We've had decisions that everyone present agreed on, that nobody wrote down, and that got relitigated a month later by people who were simply not in the room. Twice. More meetings don't fix it. What helps is accepting that verbal context has a shelf life of about a week, and writing down the small set of things that need to outlive it. ## Making decisions The article's sharpest line: waiting for certainty is itself a decision, and it carries its own cost. We'd add the small-team version. When you're 14 people, the cost of a wrong reversible decision is genuinely low. You can try a thing, hate it, and undo it inside a sprint. The cost of a *slow* decision is much higher than it looks, because the whole team is blocked on it and there's no other workstream to absorb the delay. So we bias hard toward deciding fast on anything reversible and slow on anything that isn't. Database schema, framework choice, anything that touches a customer's data: slow, written down, argued about. Which library, which folder structure, how we name things: decide in the standup, move on, revisit if it hurts. We're not always right about which bucket something is in. The tell is usually that a "small" decision keeps coming back. When something reversible gets relitigated three times, it wasn't reversible and we misjudged it. ## Influencing decisions you don't own For a manager inside a company, this means peer teams. For us it usually means the client. This is the activity we spend the most time on and the one we were worst at early on. We'd deliver a technical recommendation that was correct, watch it get declined, and conclude the client didn't get it. What was actually happening is that we were answering a question nobody had asked. The CTO's real constraint was a board meeting in five weeks. The article frames this as understanding your peers' goals, constraints, and incentives. That's the whole thing. A recommendation that ignores someone's actual constraint is a complaint with a diagram attached. What changed for us was tying the technical argument to the thing the person is actually being judged on. "This will bite us later" moves nobody. "This adds two weeks now, or roughly six weeks in Q4 when you're trying to close the round" is a sentence someone can act on. We wrote about a version of this going wrong in [the velocity metric that quietly broke our client](/en/blog/the-velocity-metric-that-quietly-broke-our-client). ## Setting direction The framework describes translating organizational priorities into something the team can act on, and modeling the standards you expect. We get the first half nearly free. There's no layer between the people deciding what to build and the people building it, so priorities don't need much translation. That's a real advantage of staying small and we don't intend to give it up. The second half is the part that doesn't care how small you are. If we say timelines are honest and then quietly pad every estimate, everyone learns the actual rule in about two weeks. If we say the standup is not a reporting meeting and then a founder uses it to check on progress, it's a reporting meeting now, whatever the docs say. Building [Arheev](/en/#products) turned out to be the most direct version of this. When you run your own product on your own process, the gap between what you claim and what you do stops being an abstraction. We found several places where our advice to clients was better than our own practice. ## Planning Getting from where you are to where you want to be, in concrete steps. Our version is deliberately short-horizon: two-week sprints with working software at the end, and a first working demo in two to four weeks. Long-range planning isn't worthless, but at our size the plan's accuracy falls off a cliff past about a month, and pretending otherwise just produces a document that makes everyone feel organized. The one thing we do plan long is people. Who's on what, who's getting bored, who hasn't touched anything new in six months. That has a much longer lead time than any technical decision, and it's the one where being late is genuinely expensive. ## What we'd take from it The six activities hold up. We'd argue the framework is describing something real and mostly invisible, and that alone makes it worth reading. What it doesn't say, and what we'd add: at a small size, three of these get easier for free and you should not mistake that for having solved them. Information arrives on its own until it doesn't. Direction needs no translation until there's a layer that needs it. The two that never get easier, at any size, are influencing decisions you don't own and modeling the standard you claim to hold. Those are also the two you can start being better at tomorrow, without reorganizing anything. *No frameworks were harmed. A few were gently disagreed with.*

We Launched a Hardware Brand (Yes, a Software Company Did That)

Norveon doo — Mon, 20 Jul 2026 00:00:00 GMT

*No soldering irons were harmed in the making of this announcement.* We're a software company. We write React, we ship mobile apps, we run an HR platform. And now we sell point-of-sale hardware. Meet [Omnotic](https://omnotic.com): our POS hardware brand for the Serbian market. Two products at launch, the THP-803 thermal receipt printer and the MPOS-M6-150 touchscreen POS terminal, aimed at cafés, restaurants, shops and warehouses. This post covers why a software company did that, and what we learned. ## The gap wasn't the hardware If you run a café or a retail shop in Serbia and your receipt printer dies mid-shift, your options are grim. Order a replacement from abroad and wait weeks. Buy from a reseller who treats support as someone else's problem. Chase warranty claims that bounce between an importer, a distributor, and a manufacturer on another continent. The hardware itself is a solved problem. Thermal printers and touchscreen terminals are mature, reliable technology. What's broken is everything *around* the hardware: availability, support, invoicing, and someone local who picks up the phone. Engineering doesn't close that gap. A brand, a sales channel, local inventory and support that actually answers do. Those happen to be things we know how to build. ## What Omnotic actually is Let's be precise about our role, because "we launched a hardware brand" can mean a lot of things. We don't design circuit boards. We selected proven devices, built the Omnotic brand around them, and took on everything a business needs to buy with confidence: - **Local inventory.** Devices in stock in Serbia. No waiting on customs. - **Domestic invoicing.** One local company on the invoice, in dinars, with proper documentation. - **Serbian support.** When something breaks at 11 AM on a Saturday, you talk to us, not a call center abroad. - **Honest products.** The THP-803 prints at 260 mm/s with a cutter rated for 1.5 million cuts. The MPOS-M6-150 is a 15-inch, IP65-rated, fanless terminal with upgradeable modules, so it doesn't become obsolete the year after you buy it. ## The part that was actually new for us Building the website was the easy part. We do that for a living. The new part was everything else: positioning a brand for an audience that doesn't care about tech stacks, setting up a sales channel from quote to delivery, writing product content in Serbian for people who measure value in shifts survived rather than features shipped, and designing support around a counter that cannot stop working. This is the same work we do for clients (brand, web, e-commerce, go-to-market), except this time the market feedback lands directly on us. When a pitch doesn't convert or a support flow frustrates someone, there's no client in between to absorb the lesson. That's now two products we run ourselves. [Arheev](https://arheev.com) taught us what it takes to build and operate software in production. Omnotic is teaching us what it takes to take a physical product to market. Both feed straight back into how we work with clients. ## What's next Omnotic launches with two products on purpose. A printer and a terminal cover the counter; everything else is noise until we've proven we can support what we sell. If you run hospitality, retail, or logistics in Serbia and your counter equipment is held together by hope, have a look at [omnotic.com](https://omnotic.com). And if you're curious what we'd build for you (the brand, the store, the whole channel), that's literally what we do. [Talk to us](/en/#contact).

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 wasn't lying 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. What nobody on that team would say out loud was this: 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: the actual work, not the dashboard. 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 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 and nothing to replace the number with. 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 picked four numbers instead of one. None of them is perfect, but 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, which 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. We don't use raw bug count, because it 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 and the cost to candidates was high, so 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 We're not grading for a correct answer or 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 and try to follow what everyone is sharing. Ask questions after. **Every few months, we challenge this format.** That includes canceling 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 free 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? It matters even more 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, matters a lot 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. When you build products, it helps a lot to understand more than the tech. 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 explain 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. It's a fair question, but 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. We got to watch every reorganization play out. ## 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." A few people from each squad spend a day updating dependencies and adding tests. Chapters meet every two weeks for knowledge sharing and 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 and give it six months. Watch for problems, and change it when it's clearly broken. You don't solve team structure. You pick 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), the mobile app for our HR platform. 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 is 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 A platform requirement like this reaches past your own code into every library in your dependency tree. When Google says "support 16KB," every native module, SDK and community package has to comply. And your migration is only done when the slowest library finally catches up. React Native makes this extra fun because you're waiting on several ecosystems at once: native iOS developers, Android developers and JavaScript developers, all trying to coordinate. 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. It works, but it's a workaround. 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. And 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. People also 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 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 to become 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, product and 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. Our team has worked fully remote since November 2023, well before Norveon was formally founded. It wasn't a pandemic response or a cost-cutting measure. 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" You can. You just build it differently. We do a weekly team call where we actually talk about what we're working on. Status updates go in Slack. The call is for technical decisions, problems we're stuck on, and 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. Nobody schedules mandatory "team building" activities. 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, since 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. We're not naturally organized people, but 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 we'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. Offices aren't evil and remote isn't perfect. We've just 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. Most companies seem to be 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. The tradeoffs are just different. 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 our team came together 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.** It doesn't wait for spare time or a slow month. 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, so the weekends were ours too. 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. We spent three weeks building a clever automated approval workflow, and 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. For a 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. We didn't read about them as consultants. We 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, and it'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 pressure and trade-offs as our clients, including 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**. Don't schedule a meeting to discuss it or write a proposal for review. 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. Only the 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 came from someone who hadn't sat through all our previous discussions and assumptions, and it 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 and reporting are all configurable. We never set out to build "the most flexible HR system." It's just 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 and 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 make 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 and no "intelligent automation" that nobody asked for. Just the basics, and they 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, and the import wasn't the slow part. 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.