Tasukiba — Build the service together, grow together
A place where building the service, respecting each other, and growing as a developer happen together.
Tasukiba and its developers grow together. No experience needed. Respect, failure-friendly. Practice TypeScript / Next.js beside your day job, one commit/month.
First, the most important thing we want to share
Thanks for opening this page. Before anything else, let us share the core idea of the Tasukiba developer community.
Build the service together. Respect each other. Grow as developers, too.
Tasukiba isn’t about just shipping a service that surfaces buried knowledge. We want it to be a place where, looking back, you can honestly say: “being part of this widened my own view of the world, too.”
That’s why we keep the door wide open.
- No prior development experience required. Experienced or beginner, both welcome
- “I want to use this as a stepping stone for my own growth” is a perfectly fine reason to join (long-term company is even better)
- Code isn’t the only contribution — testing, documentation, UX review, community moderation are all real ways in
- “Practice for the service I’ll build later” is a legitimate motivation too
Skill, title, formal background — none of those come first. “I want to give it a try” plus “I want to respect the people around me” is enough to open the door. That’s the spirit this page is written in.
Who we want to build with
Technical skill and programming experience truly aren’t required. But there is one thing we want to hold dear — the wish to respect team-based development.
And there’s one starting behavior, in my mind, that everything else flows from:
Receive someone’s opinion first, before debating it.
Just this single habit, I believe, creates a lot.
- An atmosphere where saying “I don’t know” or “please teach me” feels safe
- The ability to share your own mistakes and stuck points early, without hiding them
- And, as a result, catching risks together, before they grow into something big
—— That whole chain starts, in my view, with “not denying the other person.”
You don’t have to arrive with all of this in place
You don’t need to perform any of these behaviors perfectly from day one. Just the wish to grow them with us is enough.
I’m still someone with room to grow myself, and I want to make this a place where we practice these things together as we build. These are skills that pay back in your day job and your life, too.
Tech skill, commit count, years of experience — those, we can build up together later.
What this page is for
Service features and how-to-use are on the user-facing page. What we keep here is the layer just before that: “why we build it,” “what we want to hold dear,” and “how you yourself can grow,” as compactly as possible.
Where Tasukiba is today (for full transparency)
To be honest: Tasukiba is currently developed by Suyama alone — a small project. Which means anyone joining now becomes an early member of the community, shaping the culture from the start.
| Item | Status |
|---|---|
| Developers | 1 (Suyama) — you could be the 2nd |
| Automated tests | 141+ (Vitest + Playwright) |
| Security score | 90/100 enforced in CI |
| Operating cost | $0/mo (Vercel Hobby + Supabase Free) |
| Source code | Public repository: BusinessManagementPlatform |
| Release plan | General release: 2026-06-01 (code is already Public — feel free to look ahead) |
The “zero to one” moment of a service only comes once.
The core of the service — in one line
A service that gives humans back the creative time they should be spending, by surfacing buried data.
Most knowledge-management tools are good at storing data — and bad at using it. As the volume grows, no human can keep up. Data that nobody finds gets treated, organizationally, as “data that doesn’t exist.” Time burnt searching in meetings, mistakes from individual judgment under pressure — they keep repeating because the underlying structure stays the same.
Tasukiba aims to change that structure by surfacing past assets at the right moment, using semantic search instead of plain full-text.
The world we're trying to reach
What we actually want to build is this landscape:
Sunday night, you close the week with “I’m going to make tomorrow count” still in your chest. Monday morning, you walk into work feeling alive.
Once the time burnt on firefighting and information searching comes back, attention can finally turn from yourself to the organization around you — to mentoring people, to building psychological safety. Supporting that shift is, we believe, Tasukiba’s mission.
We also want this service to be a “third place” — alongside home and work.
Three years from now — what we want for you
While building the service, we want changes like these to happen for you, the developer. Read this as “a shared landscape we’d both like to head toward,” not as obligation.
| Area | What it looks like in 3 years (an image) |
|---|---|
| Tech stack | Hands-on experience with a modern stack — TypeScript, Next.js, PostgreSQL, pgvector, LLM integration |
| Design vocabulary | You can describe the “Middleware → Service → Repository” layering in your own words |
| Sense of quality | Test-first, security-score gates, E2E coverage feel normal to you |
| Team experience | ”Report failure → discuss → agree → move on” is in your career toolkit |
| Footing for your next step | The technical skills, network, and confidence to start the service you actually want to build |
Choosing to “graduate” mid-way to your own next step is a perfectly good outcome. This doesn’t have to be the destination.
The direction Tasukiba is heading
These are the values Tasukiba holds dear. If they resonate with you, that means a lot.
1. Surfacing buried data is the essence
Not a tool that stores data — a tool that protects users’ creative time through semantic search × surfacing. We see this as the very core of the service.
2. We want to keep the UI simple, and user agency intact
Features can grow. The UI we want to keep as simple as possible. The freedom to change plans, cancel, export data — we want to respect user agency. We’d like to stay in the spirit of “neither newcomers nor leavers turned away.”
3. We care more about “keeping it going” than “maximizing profit”
Not profit maximization, but billing for sustainability. We are not aiming for short-term big growth. Patiently, over time, delivered to the people who actually need it.
4. Beside your day job — slowly, but seriously
We do not ask for excessive commitment. A rough baseline: one commit per month is enough. “Just reading this month” is welcome during busy seasons. At the same time, if you join, we hope it doesn’t end up as a “zero-progress ghost” state — leaning on each other and lasting a long time is what we’re hoping for.
5. We discuss, we don’t fear failure, we respect each other (the core of this community)
This is not just a slogan. Concretely, we want to grow these four into operating rules.
- Role and years of experience don’t change the weight of a voice — a beginner’s naive question often catches a design blind spot
- Critique code, not people — a review is “let’s find the next step together,” not a judgment stand
- A failure report is the entry point to a prevention discussion — never a place to assign blame. The reply is “thanks for telling me”
- See people off when they graduate, with a smile — leaving isn’t a “drop-out”; it’s “graduation to the next step,” and we honor it
Making the 5th item one we genuinely live by is, we believe, the foundation that lets Tasukiba’s developer community last.
There's more than one way to contribute
If “I’m not confident in programming yet” describes you, there are still many ways in. Code is not the only contribution.
| Role | What you do | Good fit if you |
|---|---|---|
| Code development | Front / back / DB / infra implementation | want to try TypeScript / Next.js |
| Tester | New feature checks, bug reports, user-perspective feedback | notice details others miss |
| Documentation | README, FAQ, tutorials, ops manuals | enjoy writing |
| UX reviewer | Screen flow, copy, confusing-spot calls | can put the user’s feel into words |
| Discussions moderator | First-line replies on GitHub Discussions, greeting newcomers | enjoy talking with people |
| Design | Icons, logo, UI colors, diagrams | are strong on visual expression |
Even if you don’t yet know “where I’d fit” — just reach out. Finding it together, as we talk, is part of the fun.
The shape of the relationship
| Item | Content |
|---|---|
| Compensation | Volunteer pre-revenue. Post-revenue: share of results by contribution. The exact distribution rule is something we want to design with the early members |
| Commitment | Beside your day job is the baseline. One commit/month is enough. Short stints OK |
| Roles | As above (“More than one way to contribute”) — non-code is fully welcome |
| Decision-making | Important directions are discussed and agreed. No one voice decides on its own |
| ”Graduation” culture | Leaving isn’t framed as “drop-out” — it’s framed as “graduation to the next step” |
Tech stack (snapshot, May 2026)
For reference, here is the technology Tasukiba currently uses. You do not need to “already know” or “have touched” any of this. In fact, “lots of things I’ve never touched” is a feature, not a bug — it makes this a strong learning environment.
Versions and stack evolve continuously. Treat this as a May 2026 snapshot.
Click any area title to expand the details.
1. Languages / runtimes
| Tech | Version | Role |
|---|---|---|
| TypeScript | 6.x | Typed JavaScript. Shared language for front and back |
| Node.js | 22 LTS | Server runtime |
| pnpm | — | Package manager (faster, more disk-efficient than npm) |
TypeScript adds “shape (= type) of each variable” to JavaScript, so mistakes get caught early. Node.js is the engine that runs that outside the browser.
2. Frontend
| Tech | Version | Role |
|---|---|---|
| Next.js (App Router) | 16.2.6 | Unified front + server React framework. Fast builds via Turbopack |
| React | 19.2.6 | Assemble UI from “components” (reusable parts) |
| Tailwind CSS | 4.x | CSS designed via class names |
| shadcn/ui + @base-ui/react | — | Buttons, dialogs, and other UI parts |
| lucide-react | — | Icons |
| next-intl | 4.x | Internationalization (i18n) |
| react-markdown + remark-gfm | — | Markdown rendering for knowledge bodies |
| class-variance-authority / clsx / tailwind-merge | — | Dynamic Tailwind class composition |
shadcn/ui differs from typical UI libraries: instead of importing finished components, you copy the source into your own project and customize freely.
3. Backend (Next.js server-side)
| Tech | Version | Role |
|---|---|---|
| Next.js Route Handlers / Server Actions | — | API endpoint implementation |
| Prisma + @prisma/adapter-pg | 7.8.0 | Type-safe ORM (DB access layer) |
| pg (node-postgres) | 8.20 | PostgreSQL client |
| Zod | 4.x | Schema definition + input validation |
An ORM is a “translator” that lets you treat DB tables like TypeScript variables. Instead of raw SQL, you write
prisma.project.findMany()— and the compiler catches typos.
4. Database, search, vector
| Tech | Version | Role |
|---|---|---|
| PostgreSQL | 16.x (prod via Supabase’s 15.x) | RDB |
| pgvector | — | Vector similarity search (PostgreSQL extension) |
| pg_trgm | — | Fuzzy / partial-match full-text (built-in extension) |
| Voyage AI voyage-4-lite | 1024 dimensions | Text → vector (used by the suggestion engine) |
| Anthropic Claude (@anthropic-ai/sdk) | 0.92 | LLM calls (automatic tag extraction, etc.) |
Turning a sentence into 1024 numbers (a vector) means “sentences with similar meaning end up near each other.” pgvector + Voyage uses that to mechanically find “past similar projects.”
5. Authentication / security
| Tech | Version | Role |
|---|---|---|
| NextAuth.js (Auth.js) | 5.0.0-beta.31 | Auth session management (Credentials mode) |
| bcryptjs | 3.x | Password hashing |
| otplib | 13.x | MFA (TOTP / RFC 6238, Google Authenticator-compatible) |
| qrcode | 1.5 | QR code for MFA setup |
| Custom security-score check | — | Enforced at 90/100 in CI |
bcrypt stores passwords by “one-way transformation” (cannot be reversed). TOTP is the 6-digit code in your phone authenticator app; the QR is “load the secret key with your camera.”
6. External SaaS / infra
| Layer | Service | Plan | Monthly |
|---|---|---|---|
| Hosting | Vercel | Hobby | $0 |
| DB | Supabase (PostgreSQL 15, via pooler) | Free 500MB | $0 |
| Brevo | Free 300/day | $0 | |
| CI/CD | GitHub Actions | Free tier 2,000 min/mo | $0 |
The MVP is designed to run at $0/month. Vercel auto-deploys on git push. Supabase is sometimes called “the PostgreSQL version of Firebase.” Email is wrapped in a MailProvider interface — Brevo / Resend / console / inbox (E2E) switch via env vars.
7. Testing / quality
| Tech | Version | Role |
|---|---|---|
| Vitest | 4.x | Unit tests (currently 141+) |
| Playwright | 1.59 | E2E tests (browser automation) |
| ESLint 9 + eslint-config-next | — | Static analysis |
| Prettier | 3.8 | Formatter |
| E2E coverage gate | — | Custom guard catching missing E2E for new page.tsx / route.ts |
Unit tests = “is each function correct”; E2E tests = “a robot that logs in, clicks, and saves in a real browser.” Playwright is from Microsoft and drives Chrome / Firefox / Safari with one codebase.
8. Dev tools
| Tech | Role |
|---|---|
| Docker / Docker Compose | Local PostgreSQL |
| tsx | Run TypeScript directly without a build (for scripts) |
| dotenv | Load .env |
| csv-parse / jszip / diff | CSV export, ZIP generation, diff view |
| @holiday-jp/holiday_jp | Japanese holiday detection (business-day math) |
9. CI (GitHub Actions)
| Workflow | Content |
|---|---|
ci.yml | lint / tsc / Vitest / build / E2E coverage gate |
e2e.yml | Playwright E2E |
e2e-visual-baseline.yml | Visual regression tests |
security.yml | Security-score gate (fails below 90/100) |
dependency-review.yml / dependency-outdated.yml | Dependency vulnerability / outdated tracking |
10. Architecture layers
Browser
↓ HTTPS
Vercel (Next.js)
├─ Middleware (auth / RBAC)
├─ Route Handlers / Server Actions
├─ Service Layer ← business logic lives here
└─ Prisma + pg adapter
↓ Pooler (transaction mode)
Supabase PostgreSQL
(extensions: pgvector, pg_trgm)
↓ External APIs
Brevo (email) / Voyage AI (embedding) / Anthropic (LLM)
Splitting “Middleware → Service → Prisma” is about making each layer’s responsibility clear. “Reject unauthenticated visitors” → Middleware. “Project state-transition rules” → Service. “Actual DB ops” → Prisma.
To repeat: you do not need to know any of this up front. “Start with what you know” and “learn the unknown in the order you want to try it” are both welcome.
"Maybe the timing isn't right for me" — read this if that sounds familiar
“Doesn’t fit” doesn’t mean “no.” It means maybe another place can put your passion and time to better use, right now. We share these honestly as signposts. If you’re unsure, please just talk to us first. Continuing after the conversation, or choosing a different path — both are welcome outcomes.
- You already have a clear service you want to build — Your own project or company may let your passion flow more directly. Realizing it within Tasukiba may be hard
- You’re chasing short-term big profit or rapid scaling — We chose “slowly, but seriously,” so the pace you’re hoping for may not match
- You see growing features as the point in itself — On the other hand, delivering high functionality through a simple UI is very welcome
- You’d rather debate “whose fault” a failure was — That style and our “thanks for telling me” culture may not line up right now. But if you’d like to try shifting, you’re welcome too
The first step — four small steps
You do not need to decide everything in one jump. Use these steps to find your own pace.
Step 1. Read this page to the end (5 min)
If you’ve read this far — Step 1 is already done. Thank you.
Step 2. Peek at GitHub Discussions (zero pressure)
Open BusinessManagementPlatform’s GitHub Discussions. Reading is free without a GitHub account (posting will require one). Just watching the threads is fine.
There’s also a Discord community for end users. If you’d like to feel the “user side” temperature, drop in. Developer-side conversations — intros, questions, ideas — live on GitHub Discussions.
Step 3. Say hi and ask anything (at your own pace)
When you’ve got the vibe, drop a one-liner in the Introductions category — “I was just watching, got curious” is enough. Questions go in the Q&A category, anytime.
Step 4. Talk through “what I’d like to try”
Write code, try tests, fix docs, just observe first — whatever it is, let’s design your first step together. Open a thread in the Ideas category and I’ll reply.
Concrete examples of “first steps” — pick whichever feels right
| Option | What it is | Time |
|---|---|---|
| Pair-programming on a tiny task | From dev-env setup to opening a PR, side-by-side over screen-share | 30–60 min |
| Just observe | Read an existing PR / Issue and post your “this part feels good / could be better” on Discussions. No code needed | 15–30 min |
| A one-character typo PR | Fix a single typo in the docs. The smallest possible PR — also a hands-on Git / GitHub practice | 15 min |
| Read one existing test | See which code is guarded how. Share your impression on Discussions, that’s it | 20–30 min |
| Report what felt off | Try the β version, write up any rough edges as an Issue / Discussion | 15 min |
“Just reading,” “just watching,” “just asking questions” — all welcome, as many times as you like. No pressure to write code.
No rush. Stopping at Step 2, or pausing at Step 3 — both are fine, in your own time.
Timing
- Recruiting opens: 2026-06-01 (with general release)
- Before that: Say hi on GitHub Discussions any time
- GitHub: The code is already Public. Feel free to look around before deciding
The selection process will be designed later. For now, “let’s just talk first” is enough. Whatever your reason — to learn, to experience, to be involved — you’re welcome.
About the person writing this
Hi, I’m Teppei Suyama. I work in software development for my day job — quality assurance and test design — and I’m currently growing this service on my own.
“You report a failure, and the reply is thank you.” That kind of workplace, that kind of community, is something I’ve personally longed for, for a long time. I want to grow the Tasukiba developer community into that kind of place.
While building the service, I’m still very much someone with room to grow, too. Not a fixed “I teach / you learn” dynamic — let’s build a place where we grow with each other.
I’m looking forward to the day you drop in to GitHub Discussions.
For service features and overview, see the user-facing page. For more on the developer, see profile. For the service as a whole, see Tasukiba.