I started building a construction management SaaS in November 2025. About eight months later, it’s being used to manage more than $12M in project value.

Looking back, the biggest lesson wasn’t learning another framework or database. It was learning that users don’t care how elegant your architecture is if the product doesn’t solve their problem.

They only care about outcomes everything else is secondary

The best example was scheduling.

I rebuilt our scheduling feature four times.

The first version made sense to me as the developer.

The second version was technically cleaner.

The third version covered more edge cases.

The fourth version was the one project managers actually wanted because it fit how they already planned projects in Microsoft Project and allowed them to upload their existing schedules instead of forcing a completely new workflow.

That experience completely changed how I think about building software.

A few lessons that have stayed with me:

1. Spend time designing your entities and relationships. A good domain model makes everything else much easier.
2. Keep business logic in services and let controllers stay thin.
3. Design APIs around business workflows, not database tables.
4. Add validation and database constraints early to prevent bugs before they happen.
5. Build observability into production from the beginning. Monitoring and error tracking save countless hours.
6. Listen to users early and often. The code you’re most proud of isn’t always the feature customers actually need.

One of my favorite parts of backend engineering has become domain modeling. Turning concepts like BOQs, procurement, scheduling, earned value, variation orders, and cash flow into entities and services is where everything starts to click.

Once the schema accurately reflects the business, implementing services, controllers, and API endpoints becomes much more straightforward.

Lastly properly document your work.

Also I’m doing a thing whereby I talk more about my projects and experiences, I find it hard to share sometimes so I decided this is a good place to start since we are all node devs.

Happy to answer any questions about the architecture and why I made certain decisions.

FULL WEBSITE LINK

e18e (Ecosystem Performance) is an initiative to connect the folks and projects working to improve the performance of JS packages.

We'd also like to provide visibility to the efforts of countless open source developers working to cleanup, levelup, and speedup our dependencies.

We invite you to get involved in the different projects linked from these pages, and to connect with other like-minded folks.

Join us at the e18e Discord server and collaborate with our community!

Hello, I used nwjs to create a NodeJS application to work with RPG Maker MZ projects. What it does is that it reads the project, creates a list of buttons to read plugins in that project and then allows the user to edit plugin parameters without having to click through a bunch of extra UI.

It is basically a time saver application with login features for my patreon users, though I have not gotten much feedback on that login feature as of now.

Here is the itchio link with video and github links

Here is the linux github link which I work on and then transfer the app updates to the windows github link

Here's the video of me using it as well:
https://www.youtube.com/watch?v=brUfrGdk-j4

When in my beginner days, Python backend plus Svelte frontend meant two repos, two deploys, and an API layer just to wire them together. For my small and medium projects, like mine, that was always more hassle than the project itself. I just wanted one repo I could manage and ship as one thing. so back in August 2022 I started a project called fymo, to make one-repo Python+Svelte projects a normal thing to build.

I got stuck early, compiling Svelte from Python and making the two sides talk to each other was beyond me then, so it sat there for a while, like my other side projects did. between years, i came back and forth, but this time it stuck, and I finished it.

fymo renders real Svelte 5 components from Python stuff like; esbuild compiles them at build time, one long-lived Node process does the SSR, and the browser hydrates them like any Svelte app.

and the there are controllers return dicts, components get them as props. Functions (Python funcs) under app/remote/ become typed functions you import in Svelte, so there's no fetch code to write. fymo new gives you a running app with sign in. fymo generate resource posts gives you a routed page, CRUD endpoints, and a passing test file. and fymo destroy takes it back out, unless you edited the files, then it refuses.

Anything misconfigured fails at boot with the fix right there in the error message. Nothing falls back silently. that's most of the design philosophy really.

But limitations, honestly: you need Node installed (build and runtime), it's WSGI not asyncio, no ORM, one maintainer, and it's v0.20 so things still break between versions, loudly though.

Repo: https://github.com/Bishwas-py/fymo pip install fymo

Anthropic's batch API is great (50% off tokens! hell yeah!), but the DX kinda sucks. Hand-writing JSONL, tracking batch IDs, polling loops...all of which is, for me at least, really tedious.

So I built batch-kit, a CLI + library that makes it feel kinda like git:

batch add --dir ./reviews --prompt "summarize: {content}"
batch send
batch fetch --latest --output results.json

It handles the JSONL, polling, and state persistence (all the boilerplate!).

Why: Python has anthropic-batch-kit, TS didn't. Now it does. Now I'm marginally happier.

Install from npm: https://www.npmjs.com/package/@otisworks/batch-kit

It's minimal, but it works. I'm thinking about support for PDFs and other document types, config files, and (possibly?) progress bars next.

Try it, break it, and lemme know what sucks. :)

I’ve been in contact with a lot of web agencies and web developers, and I personally haven’t found many people who run their agency in a more efficient way than I do. A lot of them have too many meetings, wait too long for client approval, don’t know how to price projects, and spend way too much time on each client instead of finishing the work and moving on to the next one.

I’ve been running my agency for four years, and after a lot of trial and error, I’ve managed to make the process as efficient as possible. I wanted to share some of the steps because I think they could be valuable for anyone just starting out.

Running a web agency alone or with a partner isn’t easy because there are a lot of things to take care of. When it comes to client acquisition, I recommend focusing on either cold calling or email automation. Which one you choose depends on whether you run the agency alone or with someone else.

If you have a partner, one person can handle sales while the other focuses on building websites, connecting domains, setting up emails, and taking care of the technical work. If you’re running the agency alone, or neither of you enjoys cold calling, I highly recommend email automation.

That’s what I’ve been doing for years. It’s powerful because you can send emails at scale, set up automatic follow ups, and wait for businesses interested in a new website to reply. While you’re working on one client, another opportunity can come in without you having to stop everything and search manually.

I don’t do regular email automation where I target businesses with no website. I do the opposite and target businesses that already have one.

I use a tool called Swokei to find businesses with websites, add them to campaigns, analyze each site, score it, and generate personalized outreach emails based on problems it finds with the design, layout, speed, SEO, and mobile optimization.I schedule the campaign, set up follow ups, and wait. 

I think this approach is much better for a few reasons. You’re targeting someone who already understands the value of having a website. You’re also not just asking whether they need a redesign. You’re pointing out real problems with their current site, which makes it clear that you actually took the time to look at it. Selling also becomes easier because they’ve already paid for a website before and understand the process.

Inside Swokei, you can choose the goal of the campaign. You can offer a free draft, try to book a meeting, or simply start a conversation. I always choose the free draft because that has worked best for me.

Once you’ve figured out how to get clients, the next part is building the website. I recommend using AI because it makes the process much faster. For anyone who still thinks AI can’t build great websites, I think they’re mistaken. You can use Claude, Base44, Lovable, or any other tool that works for you.

When someone replies interested, I call them and say, “Hey, I saw that you replied to my email. I’ve already built you a free draft of your website. Do you want to take a look?”

Then I invite them to a Google Meet.

At that point, it becomes much harder for them to reject the meeting because they already replied interested and now know you’ve built something for them. During the meeting, I present the website, explain why it’s better than their current one, stack the value, answer their questions, and try to close the deal.

These meetings usually go well because the client isn’t trying to imagine what the website might look like. They can already see a better version of their current site. They also took the time to join the meeting, so taking the next step becomes much easier.

I either take payment during the meeting or send them a contract to sign. Any changes and updates come after that, once we already have a deal in place.

Pricing depends on the business. I charge anywhere from $500 to $3,000 depending on the company, the size of the project, and how much value the website can bring them. I also charge a monthly retainer of around $50 for hosting, maintenance, support, SEO, and future changes.

That’s basically the entire process. Smaller steps, faster delivery, less wasted time, and more money made.

Found it here