<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Striving Designs — Build Log</title>
    <link>https://strivingdesigns.com/log</link>
    <description>Independent product studio refining complex problems into specialized software tools.</description>
    <language>en-us</language>
    <lastBuildDate>Thu, 09 Apr 2026 02:57:00 GMT</lastBuildDate>
    <atom:link href="https://strivingdesigns.com/feed.xml" rel="self" type="application/rss+xml" />
    <managingEditor>prayas@strivingdesigns.com (Prayas Shrestha)</managingEditor>
    <webMaster>prayas@strivingdesigns.com (Prayas Shrestha)</webMaster>
    <image>
      <url>https://strivingdesigns.com/logo.png</url>
      <title>Striving Designs</title>
      <link>https://strivingdesigns.com</link>
    </image>

    <item>
      <title><![CDATA[Building the Nurse Ledger Engine on Device]]></title>
      <link>https://strivingdesigns.com/log/building-the-nurse-ledger-engine</link>
      <guid isPermaLink="true">https://strivingdesigns.com/log/building-the-nurse-ledger-engine</guid>
      <description><![CDATA[Why we built a complete unit-testable calculation core before a single UI screen exists.]]></description>
      <content:encoded><![CDATA[
Most mobile apps start with Figma. They start with the UI, the "feel," and the onboardings. For **Nurse Ledger**, we did the opposite. 

We started with a spreadsheet. Specifically, a spreadsheet of every nursing pay category in the US: night differentials, weekend premiums, charge nurse pay, certification bonuses, travel stipends, PRN waivers, and overtime rules that vary by state (hello, California).

## High Precision, Low Drama
A pay calculator is only as good as its last result. If a nurse trusts our app and it gives them a number that's off by $20 on a paycheck, we have lost that user forever. Trust is the only currency here.

That's why Task #1 for Phase 1 was building a logic-only Core Engine. No React Native UI, no Supabase connection, no navigation. Just pure TypeScript functions and a heavy Jest test suite.

## The "Blended Rate" Problem
One of the trickiest parts of US nursing pay is the "blended rate." If you earn a base rate of $50, but you have a $2 BSN differential and a $5 weekend premium, your "regular rate" for overtime purposes is $57. California law, in particular, requires overtime to be calculated on this blended rate, not just the base.

Our engine now handles all 14 major pay categories and properly calculates these blended rates across 70+ parameters. 

## Testing for Truth
We now have 15 core tests passing, covering everything from Sarah's PRN Saturday shift to complex California holiday overtime scenarios.

```bash
 PASS  engine/__tests__/calculate.test.ts
 ✓ calculates base pay correctly without differentials
 ✓ calculates base pay + education + certification + role differentials
 ✓ calculates the exact spec scenario: Sarah PRN Saturday
 ✓ calculates partial shift time boundaries (evening/night) & holiday multipliers
 ✓ calculates California overtime utilizing the blended rate
```

The repo is now connected to GitHub, and CI is being set up. The foundation is set. Now we can start building the UI with the confidence that the math is already "shipped" in our heads.
]]></content:encoded>
      <pubDate>Sun, 29 Mar 2026 00:00:00 GMT</pubDate>
      <category>nurse-ledger</category>
      <category>engineering</category>
      <category>react-native</category>
    </item>
    <item>
      <title><![CDATA[Fighting Terminal UI: The Evolution of Strive-Sync]]></title>
      <link>https://strivingdesigns.com/log/strive-sync-evolution</link>
      <guid isPermaLink="true">https://strivingdesigns.com/log/strive-sync-evolution</guid>
      <description><![CDATA[Building a CLI dashboard in Bash sounds simple until you hit deep directory paths and parallel process management. Here is how I hardened Strive-Sync into a production-ready tool.]]></description>
      <content:encoded><![CDATA[
Working in a polyrepo as a solo developer is a constant trade-off. You get clean history and isolated deployments, but you lose the "one command to rule them all" simplicity of a monorepo. But Strive-Sync didn't actually start with my studio. It started at my day job.

We manage a project split across 10 or 11 different repositories. My morning routine was a ritual of manual labor: switch directories, `git pull`, check lockfiles, run `npm install`, and repeat ten more times. It was a tedious, time-thieving task. 

I wrote a quick script to automate it for myself, and it worked so well that I shared it with my teammates. Seeing their reaction made me realize that this wasn't just my friction, as it was an industry-wide annoyance. 

When I started building out the Striving Designs ecosystem, I realized the studio needed the same tool. Coordinating PraxorAI, the platform site, and our CLI tools was creating that same "sync drag." I decided to polish that internal script, harden it for public use, and release it as the first official tool in the Strive-CLI suite.

But building a CLI tool that looks good and stays reliable for the public is harder than it looks.

## The "Accordion Collapse" Problem

The first iteration of Strive-Sync had a significant visual bug. I wanted a real-time dashboard that showed the status of every repository in the workspace. It worked perfectly in my test directory where paths were shallow.

However, as soon as I ran it against a larger workspace (like the 11-repo monster at work), the dashboard would literally collapse. High-depth file paths were out-pacing the terminal width, causing ANSI escape codes to wrap and overwrite previous lines. It looked like a broken accordion. 

I solved this in v1.2.0 by moving to an "identity-first" HUD. Instead of showing the full relative path, the tool now truncates from the middle or the start, prioritizing the unique product name while keeping the status indicators perfectly aligned on the right.

## The "Main vs Master" Dilemma

Another friction point was branch detection. Not every repository uses `main` as the default branch. Some older projects still use `master`, and others might have custom integration branches. 

Manually specifying the branch for every repo in a `.repos` file felt like exactly the kind of "chore" I was trying to avoid. The solution was a more intelligent `detect_default_branch` function. It now queries the local git config and the upstream `HEAD` reference to determine the correct target before attempting any sync. No more manual overrides required.

## Hardening for Production

The final hurdle was stability. Running parallel git operations in Bash can create "zombie" processes if the parent script is interrupted (like with a `Ctrl+C`). 

I spent a good chunk of development time refining the `cleanup()` trap. It now ensures that every background worker is caught and terminated properly, leaving the terminal state clean and the session memory intact. 

## Strive-Sync v1.2.0

With the addition of the pre-flight review flow and the `--yes` flag for non-interactive triggers, Strive-Sync has graduated from a "helpful script" to a core part of the Striving Designs workflow. 

It's not just about syncing code. It's about removing the mental friction of context switching. When I start my day, I run one command, and I know my entire empire is in sync and ready to go.
]]></content:encoded>
      <pubDate>Sat, 28 Mar 2026 00:00:00 GMT</pubDate>
      <category>strive-cli</category>
      <category>engineering</category>
      <category>polyrepo</category>
    </item>
    <item>
      <title><![CDATA[Technical Depth as a Studio Asset]]></title>
      <link>https://strivingdesigns.com/log/technical-seo-identity</link>
      <guid isPermaLink="true">https://strivingdesigns.com/log/technical-seo-identity</guid>
      <description><![CDATA[Moving beyond basic metadata to build a machine-readable search identity.]]></description>
      <content:encoded><![CDATA[
Striving Designs exists to distill complexity into utility. Usually, that means building better interfaces for humans. Today, I applied that same philosophy to how machines read this studio.

The current SEO landscape is noisy. Most advice focuses on keyword density or backlink hacks. For a specialized product studio, those tactics are distractions. Real authority comes from semantic clarity.

I implemented a four-tier technical strategy to solidify this studio's identity.

**Identity and Authority**
I started by mapping strict canonical URLs and advanced metadata. This ensures search engines see one single source of truth for every page. It removes the ambiguity that often causes indexing penalties in larger, messier sites.

**Machine-Readable Semantics**
I built a dedicated system for JSON-LD structured data. This explicitly tells search engines that Striving Designs is a validated Organization and a Product Studio. By defining these entities in code, I am reducing the time it takes for Google to trust the domain.

**Rich Snippet Architecture**
I added Article and Breadcrumb schemas to this build log. This is not about ranking higher; it is about visibility. These schemas ensure that our search results show as professional snippets with dates, author tags, and clear navigational paths. It turns a standard link into a high-signal entry.

**Performance as a Standard**
SEO is fundamentally tied to performance. I audited our asset pipeline to prioritize Largest Contentful Paint. The site remains text-centric and asset-light. Speed is a technical requirement, not a feature.

This infrastructure is now a permanent part of the studio. It ensures that when I ship new tools, the technical foundation is already there to support them.
]]></content:encoded>
      <pubDate>Mon, 23 Mar 2026 00:00:00 GMT</pubDate>
      <category>technical-seo</category>
      <category>engineering</category>
      <category>striving-designs</category>
    </item>
    <item>
      <title><![CDATA[PraxorAI is close. Here's what the MVP actually means.]]></title>
      <link>https://strivingdesigns.com/log/praxorai-mvp</link>
      <guid isPermaLink="true">https://strivingdesigns.com/log/praxorai-mvp</guid>
      <description><![CDATA[An MVP is the smallest version of a product that genuinely solves a core problem for a real user. For PraxorAI, that means a creator can drop in their assets and get back something they could actually post.]]></description>
      <content:encoded><![CDATA[
Right now, PraxorAI has one goal: shortening the distance between a creator's idea and a published post. For me, an MVP isn't just a bare minimum version. It is the smallest unit of software that solves a core friction with real results.

For PraxorAI, that means a creator can drop in raw assets like scripts, audio, or lyrics, and get back a finished vertical video that is statistically and visually ready for distribution.

## The Friction: Production Latency
The faceless content market (like lyric channels, quote videos, and data visualizations) is currently bottlenecked by manual production. Creators are spending hours in traditional video editors performing repetitive tasks: timing subtitles, sourcing visuals, and manually exporting for multiple platforms.

I like to treat video production as a data pipeline problem rather than a creative chore.

## The Solution: A Direct Pipeline
I'm building an engine that handles the entire content chain:

- **Logic-Driven Timing:** Aligning visual elements to audio or text triggers automatically.
- **Automated Composition:** Dynamic vertical layouts optimized for mobile-first platforms.
- **API-Driven Distribution:** Direct authenticated posting to YouTube Shorts and TikTok, bypassing the manual file management step entirely.

## Studio Status
PraxorAI is not quite done yet, but it is my primary focus right now and getting very close to MVP status. The core rendering engine is stable, and I am currently finalizing the distribution layers to ensure a one-click workflow for creators.

Efficiency is the primary requirement here. Production should be an output, not a bottleneck.
]]></content:encoded>
      <pubDate>Sat, 21 Mar 2026 00:00:00 GMT</pubDate>
      <category>ai</category>
      <category>saas</category>
    </item>
    <item>
      <title><![CDATA[Why I'm building a pay calculator for nurses.]]></title>
      <link>https://strivingdesigns.com/log/nurseled-origin</link>
      <guid isPermaLink="true">https://strivingdesigns.com/log/nurseled-origin</guid>
      <description><![CDATA[Nurse compensation is remarkably complex. Generic calculators fail because they don't account for the 14 pay categories that define a nursing contract.]]></description>
      <content:encoded><![CDATA[
The whole point of Striving Designs is finding those deeply frustrating problems that general-purpose software ignores. Nurse compensation is a perfect example.

Nurse pay in the US is remarkably complex. It isn't just a base rate and hours. It involves a massive multi-parameter calculation including night differentials, weekend premiums, travel stipends, PRN waivers, and certification adjustments. 

In my research, I found that most healthcare professionals are still relying on extremely complex and brittle Excel spreadsheets to verify their own earnings. Generic pay calculators fail because they simply don't account for the 14 distinct pay categories that define a modern nursing contract.

## The Friction: Information Asymmetry in Pay
Nurses often find discrepancies in their paychecks, but the effort required to manually reconcile over 70 parameters against a complex pay stub is exhausting. Travel nurses in particular face the added complexity of stipend taxability and PRN waiver arrangements.

## The Solution: NurseLedger
NurseLedger is a specialized financial utility I am building specifically for nursing logic. 

- **14 Pay Categories:** Built-in logic for every standard nursing premium.
- **Contract-Centric:** Designed to handle 13-week travel contracts and PRN floating schedules.
- **Verification-First:** A companion tool for high-confidence reconciliation of every single paycheck.

## Studio Status
Both NurseLedger and my other upcoming project ChorPact are currently in their initial development phases. For NurseLedger, I am actively refining the core calculation engine to perfectly handle the edge cases of tax-free stipends for travel nursing and PRN overtime logic. 

I don't believe in building generic calculators. I prefer building tools that actually respect the true complexity of a professional's domain.
]]></content:encoded>
      <pubDate>Thu, 12 Mar 2026 00:00:00 GMT</pubDate>
      <category>product</category>
      <category>healthcare</category>
    </item>
    <item>
      <title><![CDATA[Launching Striving Designs: A refocus on craft.]]></title>
      <link>https://strivingdesigns.com/log/striving-designs-launch</link>
      <guid isPermaLink="true">https://strivingdesigns.com/log/striving-designs-launch</guid>
      <description><![CDATA[Everything starts with a choice. For me, Striving Designs is the choice to focus entirely on software that solves real, frustrating problems without the corporate noise.]]></description>
      <content:encoded><![CDATA[
Everything starts with a choice. For years, I have been building software in various environments, but I always found myself pulled toward a specific kind of work: tools that solve real, localized frictions for people who are just trying to get things done.

Striving Designs is my refocus on that singular goal.

## The History of the Domain
Actually, strivingdesigns.com has been in my pocket since 2006. I registered it back then with the dream of starting a web design studio. Life eventually took me in different directions, and for twenty years, the domain was just a quiet reminder of an unfinished goal. 

I never quite let go of the idea, though. I kept renewing it year after year, waiting for the right moment and the right perspective. Now, as I step into this new chapter of building specialized tools, it finally feels like the era I was waiting for. The dream from 2006 finally has its foundation. It is no longer a placeholder. It is the center of everything I am building.

I wanted to build a studio that reflects my personal philosophy. I call it high signal and low drama. It means building tools that are excellent at one thing and stripping away all the fluff that usually gets in the way.

## Why now?
The software world currently feels very loud. There are too many growth hacks, too much distracting UI, and too many products that feel like they were built for investors instead of users. 

I prefer the opposite. 

I want to build software that feels quiet, reliable, and incredibly useful. Whether it is a pay calculator for nurses or an automated video pipeline for creators, the goal is always the same: distill the complexity so the professional can focus on their actual work.

## Studio Status
The studio is now officially live. This very site is the first artifact of that shift. It is simple, it is fast, and it exists purely to showcase the products I am building. 

I have a few projects already in flight. PraxorAI is nearing its first version, and both NurseLedger and ChorPact are moving through their initial development. 

I will be using this log to document the build process for all of them. No stressful schedules or marketing spam. I will just share things here when they are actually worth sharing.

It is good to be building again.
]]></content:encoded>
      <pubDate>Sun, 01 Mar 2026 00:00:00 GMT</pubDate>
      <category>studio</category>
      <category>launch</category>
    </item>
  </channel>
</rss>