Every board election, HOA vote, or association ballot tends to run into the same problems: mailed ballots that get lost or arrive late, volunteers spending a weekend hand-counting paper, and no real way to know who’s voted until it’s too late to remind them. We built Elections Manager to fix that.

What is it?

Elections Manager is a cloud-based SaaS for running electronic elections (or any poll for that matter) — no software to install, no committee IT project, and no monthly subscription. You pay only when you actually run an election.

How it works

Running an election takes seven steps, all inside the app:

1. Create an election.
2. Add ballot items — each one has a position (President, Board Member, a bylaws vote, whatever your organization needs) and the candidates or options running for it.
3. Upload your voter list — just an email address plus first and last name for each voter.
4. Set the date polling opens and the date it closes.
5. Choose a scoring method for each item: plurality or ranked-choice.
6. Voters get their ballot by email and vote electronically during the polling window.
7. Compile and email results whenever you’re ready — one click.

Built for how real organizations vote

We support two scoring methods, so you can pick whichever fits the race being contested — no separate setup required:

• Plurality — most votes wins.
• Ranked-choice — voters rank candidates, and the lowest performer’s votes redistribute until someone has a majority.

And it’s built for the kinds of organizations that actually run these elections: HOAs and condominium associations, professional and trade associations, nonprofits and member organizations, clubs, cooperatives and alumni groups, private-company board and shareholder votes — and everyone else with a group that needs to vote on something.

Why go electronic

• No mail-in ballots. No waiting on the mail, no printing or postage costs.
• No ballots lost or discarded in transit.
• Results in minutes, not a weekend of volunteers hand-counting paper.
• Every vote is tied to a verified voter on your uploaded list — no duplicate ballots.
• Turnout visible automatically — no hand-tallying who’s voted so far.

Pay only for what you use

There’s no monthly subscription — pricing is pay-as-you-go, per election:

You’ll always see the final price before checkout.

Get started

Create your organization, build your first ballot, and upload your voter list — you can be ready to open polling in minutes.

Get started →

If you’ve ever opened a tsconfig.json file, tweaked a setting, and prayed your build didn’t break, you’re not alone. TypeScript’s compiler settings can feel like a labyrinth of overlapping keywords. Four options in particular cause endless head-scratching:

• target
• module
• moduleResolution
• esModuleInterop

While they all sound like they’re doing the exact same thing (handling JavaScript modules), they actually control very distinct phases of compilation and module resolution.

Here is the ultimate mental model to untangle them once and for all.

The Quick Mental Model

To keep them straight, assign each setting a specific role in your build pipeline:

1. target: Modern Syntax vs. Legacy Compatibility

target dictates the version of JavaScript syntax TypeScript outputs when it strips out your types. It controls syntax features like async/await, arrow functions, classes, and optional chaining.

Important: target does not change how your import and export statements are written—unless your module setting depends on it!

Example

Imagine you write this TypeScript code:

const greet = (name: string) => {
  console.log(`Hello, ${name}?.length`);
};

• "target": "ES2020" → Outputs modern arrow functions and template literals as-is.

const greet = (name) => {
  console.log(`Hello, ${name}?.length`);
};

• "target": "ES5" → Transpiles everything down to old ES5-compatible code using regular functions and string concatenation.

var greet = function (name) {
  console.log("Hello, " + (name === null || name === void 0 ? void 0 : name.length));
};

2. module: The Module Format of the Output

While target controls JS syntax, module controls how files import and export other files in the generated .js output.

Common JS module systems include:

• CommonJS (CJS): Uses require() and module.exports (traditional Node.js).
• ES Modules (ESM): Uses import and export (modern browser & Node.js standard).

Example

Suppose your TypeScript code imports a helper:

import { add } from './math';
export const result = add(1, 2);

• "module": "CommonJS"

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const math_1 = require("./math");
exports.result = (0, math_1.add)(1, 2);

• "module": "ESNext" (or ES2022)

import { add } from './math';
export const result = add(1, 2);

3. moduleResolution: How TS Finds Your Files

moduleResolution tells the TypeScript compiler the algorithm to use when searching for a module when you write import something from 'location'.

It doesn’t affect your compiled JS code at all. It strictly exists for compile-time type checking.

Common Values:

1. node10 (formerly node): Mimics older Node.js require() lookup behavior. Looks in node_modules, searches for index.js or package.json “main” fields.
2. node16 / nodenext: Built for modern Node.js which supports both ESM and CJS natively. It respects package.json "exports" fields and requires file extensions (like .js) in relative import paths!
3. bundler: Designed for apps using modern bundlers (Vite, Webpack, esbuild). It respects "exports" like node16, but relaxes rules like requiring explicit .js extensions in imports.

Example

import { helper } from './utils';

With node16, TypeScript will yell at you:

Relative import paths must end with an extension. You’d have to write ./utils.js (even though the source file is ./utils.ts).

With bundler, TypeScript lets ./utils pass without complaint because your bundler handles extension resolving for you.

4. esModuleInterop: Smoothing Over CJS & ESM Friction

Historically, CommonJS modules exported a single default value like this:

// lodash in CommonJS
module.exports = function () { /* ... */ };

ES Modules require explicit default exports (export default ...). When ESM code tries to import a CJS package, syntax friction happens:

// Standard ES Module spec requires this:
import React from 'react'; 

// But without esModuleInterop, TS forced you to do this for CJS libs:
import * as React from 'react';

Setting "esModuleInterop": true tells TypeScript to emit tiny helper functions in the JavaScript output so you can use standard import React from 'react' syntax seamlessly, even when importing legacy CommonJS modules.

Example

import express from 'express';

• "esModuleInterop": false → Fails compilation or runtime error because express exports via module.exports, not an ES default export.
• "esModuleInterop": true → TS wraps the require('express') in an __importDefault helper under the hood so your clean ES import default syntax just works!

Summary Checklist

When configuring your next project, ask yourself:

1. target: How old are the browsers or Node runtime I am deploying to? (e.g., ES2022)
2. module: What module system does my target runtime execute? (e.g., NodeNext for modern Node, ESNext for Vite/Frontend)
3. moduleResolution: Who is bundling or running my code? (e.g., bundler for Webpack/Vite, nodenext for pure Node)
4. esModuleInterop: Am I importing CommonJS libraries into an ESM project? (Set to true 99% of the time!)

A few days ago I noticed something odd in my Spring Boot app’s logs: a fresh “Initializing Spring embedded WebApplicationContext” line, out of nowhere, in the middle of otherwise normal operation. No stack trace. No OutOfMemoryError. No exception at all — just the app quietly starting up again, as if nothing had happened.

That’s the annoying kind of bug. When the app itself logs an error, you at least know where to look. When it logs nothing, you’re debugging a crime scene with no witnesses.

Here’s how I tracked it down.

Step 1: Ask systemd what it saw

Since the app is run as a systemd service (my-app.service), the first move was to check systemd’s own record of what happened:

systemctl status my-app.service

This showed the service as healthy and running, with an uptime that lined up with the restart — not hugely informative on its own, but it confirmed the service was in fact bounced, not just logging something weird.

Step 2: Pull the journal around the exact restart time

Application logs only tell you what the app chose to log. Systemd’s journal tells you what actually happened to the process — stops, starts, exit codes, signals.

journalctl -u my-app.service --since "<restart-time-minus-2min>" --until "<restart-time-plus-2min>"

e.g.:

journalctl -u my-app.service --since "2026-08-11 15:27:13 UTC" --until "2026-08-11 15:30:13 UTC" -o cat | cat

This is where the trail actually started. The output showed:

systemd[1]: Stopping my-app.service...
systemd[1]: my-app.service: Deactivated successfully.
systemd[1]: Stopped my-app.service.
systemd[1]: my-app.service: Consumed 20min 58s CPU time, 1.8G memory peak, 0B memory swap peak.
systemd[1]: Started my-app.service.

Two things stood out immediately:

1. “Deactivated successfully” — this was not a crash. A crash shows up as a nonzero exit code or a kill signal. This was a clean stop, meaning something intentionally told the service to stop.
2. 1.8G memory peak — worth noting for later, since my JVM heap was capped at -Xmx768m. The total footprint (heap + metaspace + thread stacks + native buffers) had crept well past that. Not the cause of this particular incident, but a red flag worth fixing separately.

Step 3: Widen the net — what else happened at that exact second?

A clean stop means something else on the system triggered it. So instead of filtering to just my service, I pulled the entire system journal for that window:

journalctl --since "<restart-time-minus-2min>" --until "<restart-time-plus-2min>"

This was the payoff. The full log showed a very telling sequence, all within the same second:

systemd[1]: Starting apt-daily-upgrade.service...
apt.systemd.daily: [unattended-upgrade running]
systemd[1]: Stopping other-service-A.service...
systemd[1]: Stopping other-service-B.service...
systemd[1]: Stopping my-app.service...
systemd[1]: other-service-A.service: Deactivated successfully.
systemd[1]: Started other-service-A.service.
systemd[1]: other-service-B.service: Deactivated successfully.
systemd[1]: Started other-service-B.service.
systemd[1]: my-app.service: Deactivated successfully.
systemd[1]: Started my-app.service.

Three completely unrelated services — all running on the JVM, all otherwise unconnected to each other — restarted within the same second, immediately after an unattended package upgrade. That’s not a coincidence; that’s a pattern.

Step 4: Confirm the suspect — needrestart

That pattern is the signature of needrestart, a tool that ships with Ubuntu’s unattended-upgrades setup. Its job: after a security patch updates a shared library (things like libssl, libtinfo, libnghttp2), it scans running processes to see which ones are still linked against the old version of that library still sitting in memory, and restarts them so they pick up the patched version.

A quick check of the unattended-upgrades log confirmed the timing lined up exactly with a batch of library upgrades:

cat /var/log/unattended-upgrades/unattended-upgrades.log

INFO Packages that will be upgraded: libncurses6 libnghttp2-14 libtinfo6 ...
INFO All upgrades installed

And checking needrestart’s config confirmed it runs in fully automatic mode when triggered by apt:

cat /etc/needrestart/needrestart.conf | grep -i restart

# UBUNTU: the default restart mode when running as part of the APT hook is 'a',

'a' = automatic. No prompt, no notification, no log line in my app’s own output — it just quietly restarts anything it flags, which is exactly why the only trace in the application log was a fresh startup banner.

Mystery solved: my three JVM-based services all got swept up in a routine security patch restart, triggered by needrestart after unattended-upgrades patched some shared libraries.

Takeaways

• A clean restart with no app-level error is a strong signal to look outside the application — systemd, the kernel, or another process is a more likely culprit than your own code.
• journalctl -u <service> narrows the view; a plain journalctl (no unit filter) widens it. The second one was the key here — it revealed the surrounding system activity that the per-service view couldn’t show.
• If multiple unrelated services restart at the exact same moment, look for a shared dependency, not a shared bug. In this case the shared thread was “runs on the JVM,” and the trigger was a routine library patch.
• Automatic security patching is generally a good thing. Once I understood the cause, the fix wasn’t to disable it — it was simply to know that this kind of brief, clean restart is expected behavior, not an incident.

Debugging checklist for “my service restarted and there’s no error”

1. systemctl status <service> — is it actually a clean stop or a crash/kill?
2. journalctl -u <service> --since ... --until ... — narrow to the exact window
3. journalctl --since ... --until ... (no unit filter) — widen to see the whole system at that moment
4. dmesg -T | grep -i oom and journalctl -k | grep -i oom — rule out the OOM killer
5. systemctl show <service> -p MemoryMax — rule out a cgroup memory limit
6. Check /var/log/unattended-upgrades/ and needrestart config if the timing lines up with routine patching

Sometimes the most reassuring outcome of a debugging session isn’t finding a bug — it’s finding out there wasn’t one.