- Starting price
- Free public pages; beta creator access
- Free tier
- Yes
- Platforms
- Web · RSS · email lead capture · GitHub source
- Developer
- Cameron Pak / faith.tools
- Launched
- 2024
- Updated
- Aug 9, 2026
The verdict
Keep in Touch solves a real early-product problem with unusual restraint. A builder gets one understandable page, updates that can travel by RSS, a lightweight email-interest list, and discovery inside the audience most likely to care. The public source code and MIT license make the experiment more trustworthy and reusable than a closed waitlist tool. It is still an experiment, not a mature launch platform: creator onboarding is not self-explanatory, pricing and service guarantees are not published, project exports and subscriber consent controls need clearer documentation, and the latest visible product update is months old. Use it as a low-cost companion page and feedback channel, keep your canonical domain and independent subscriber backup, and do not make it the only place your product, audience, or launch history lives.
Try Keep in Touch (kit) ↗Opens kit.faith.tools
Keep in Touch, usually styled simply as kit, is a small publishing and audience-building service inside the faith.tools ecosystem. It was created for a stage most directories and launch sites handle poorly: a Christian developer, designer, ministry, or founder is building something worth discussing, but the product is not polished enough for a conventional launch. A kit page can explain the idea, name the maker, present a call to action, collect expressions of interest, and publish progress without pretending the project is finished.
The public feature set is compact but coherent. Each project can receive a no-code overview page, an update blog, an RSS feed, email lead capture, page-view counts, QR-code sharing, a configurable call to action, and promotion through faith.tools. Posts visible on kit’s own page document additions such as webhooks, publishing controls, CRUD support, page analytics, safer AI-assisted moderation, and shared authentication. In March 2026, Cameron Pak announced that signing in to kit also signs a user into faith.tools, laying technical groundwork for closer directory participation.
Kit is also genuinely open source. Its public GitHub repository identifies Astro, HTMX, Alpine.js, Tailwind CSS, DaisyUI, Clerk, Turso, and Cloudinary in the stack, includes deployment instructions, and uses the MIT license. The repository was created in October 2024 and showed a March 9, 2026 push when checked. Open code does not automatically make the hosted service private, reliable, or easy to migrate, but it lets technical users inspect implementation, report issues, operate a fork, and see that “open source” is more than a marketing label.
The maturity gap is equally visible. The official page still calls kit a beta, the public “Claim your kit” flow does not present a normal self-serve plan table, and the project has a very small public GitHub audience. Its footer points to the broader faith.tools terms and privacy pages rather than a detailed kit-specific data guide. We researched the live project page, all visible update titles, RSS output, public repository metadata, README, license, and linked policies. We did not claim a creator page, collect a lead, test deliverability, inspect the private dashboard, audit the database, or operate a self-hosted installation.
✓ The good
- Clear early-stage job - it gives unfinished Christian products somewhere honest to explain progress and gather feedback
- Useful minimum feature set - landing page, posts, RSS, lead capture, analytics, QR sharing, and calls to action reinforce one another
- Built-in niche discovery - project pages can be surfaced to the faith.tools audience instead of beginning with zero distribution
- Open-source implementation - the MIT repository can be inspected, forked, improved, or self-hosted by capable teams
- Portable update channel - RSS lets readers follow progress without surrendering an email address or depending on an algorithmic feed
- Visible build history - public posts record product decisions and changes instead of presenting a mysterious static beta
- Shared ecosystem sign-in - one account across kit and faith.tools reduces friction and can support future directory participation
- Human-scale product - the interface avoids the campaigns, funnels, automations, and configuration overload of a full marketing suite
✗ Watch out
- Still labeled beta - availability, interfaces, onboarding, and integrations can change without mature-service guarantees
- Creator access is unclear - the public page invites a claim but does not publish a complete self-serve eligibility and onboarding path
- No clear hosted pricing table - builders cannot compare limits, future charges, storage, contacts, sends, support, or paid guarantees
- Kit-specific privacy detail is thin - project owners need an exact data map for leads, analytics, moderation, images, authentication, retention, and deletion
- Small public adoption evidence - a handful of stars, one fork, and sparse independent discussion do not establish dependable scale
- Audience portability needs proof - RSS moves posts, but full subscriber, consent, analytics, media, and project export behavior is not prominently documented
- Single-ecosystem concentration - visibility depends heavily on faith.tools and the continued attention of a small founder-led project
- Not a full launch stack - custom domains, campaigns, segmentation, transactional email, experiments, CRM, and support workflows need other tools
Best for
- Christian developers and designers sharing a product before it is ready for a formal launch
- Open-source ministry projects that value RSS, public progress, and a simple call to action
- Small teams that need a temporary validation page without learning a large marketing platform
- Builders already participating in faith.tools who want relevant directory discovery
- Technical users willing to inspect or fork the source if the hosted experiment changes
Avoid if
- Your launch requires service-level guarantees, formal support, enterprise security review, or a stable paid contract
- You need advanced email campaigns, segmentation, CRM stages, custom automation, A/B testing, or sales attribution
- Your subscriber data cannot pass through third-party authentication, database, image, analytics, or hosting vendors
- You need a proven custom-domain and full-data-export workflow before collecting an audience
- Your product serves a broad market and gains little from faith.tools-specific distribution
What Keep in Touch (kit) is
Kit sits between a social update and a complete product website. A creator can describe what is being made, provide one next action, collect interest, and publish a chronological build log. That is enough for validation, early feedback, and a public record. It does not try to manage the finished product, billing, customers, support tickets, documentation, or a complete marketing funnel.
The hosted service and the open-source project are related but not identical promises. The repository gives developers the application code and a permissive license. The hosted site adds the operating environment, shared faith.tools identity, directory promotion, storage, moderation, and ongoing maintenance. A team evaluating risk should inspect both layers: what the code permits and what the live operator promises about data, continuity, and support.
Why Christian builders use kit: relevant visibility before a polished launch
A generic landing-page service can collect email addresses, and a generic build-in-public network can host updates. Kit’s advantage is the connection between those functions and a curated Christian technology audience. A prototype for church operations, prayer, Scripture engagement, missions, generosity, or family discipleship can be shown to people who understand its intended setting before the maker spends months polishing the wrong thing.
That relevance should not become dependence. A kit page works best as a bridge to an owned domain, source repository, app store, store page, or documented product when the project matures. Builders should export contacts where consent permits, publish the same major updates through an independent channel, and make it easy for readers to identify who controls their information. The niche audience is the accelerant; durable ownership is the foundation.
Project page and call to action: enough structure to test an idea
A kit page gives the project a title, creator identity, description, media, and a configurable action such as getting updates, learning more, or preregistering. The format forces a useful discipline: explain the user problem and next step without hiding behind a complex website. QR sharing extends the same page to events, meetups, church presentations, or printed material.
Treat the page as a testable proposition. State who the project serves, what it does now, what is only planned, and what kind of feedback is wanted. Avoid implying that a prototype is secure, clinically safe, licensed, complete, or broadly adopted. If the call to action collects information, place purpose, frequency, sender identity, unsubscribe behavior, and a policy link beside the form—not somewhere a visitor must hunt.
Updates, RSS, and leads: a tiny audience system with real portability
Project posts create a dated build log and automatically expose an RSS feed. Email lead capture lets an interested visitor request updates, while webhooks and publishing improvements documented in the public history suggest room for connecting outside workflows. Page views provide a basic signal that a project is being seen, though views are not the same as qualified interest or adoption.
RSS is the strongest portability feature because it is an open reading standard and does not require another platform account. Email is more sensitive: a creator should know whether consent evidence, source, timestamp, unsubscribe state, suppression list, export, and deletion travel with each contact. Keep a separate consent-respecting system of record if losing the list would materially harm the project.
Open source and shared sign-in: transparent foundations, shared responsibility
The public repository documents a modern web stack and an MIT license. Shared sign-in with faith.tools makes the hosted service feel more like one ecosystem than a disconnected microsite. For contributors, source access supports bug reports, security review, local development, and forks. For ordinary creators, it reduces the risk that the tool’s basic ideas disappear if the hosted experiment ends.
Operating a fork is not a one-click escape. Authentication, database, image hosting, email delivery, spam controls, backups, updates, privacy requests, and incident response become the operator’s responsibility. Likewise, shared authentication concentrates account risk and requires clear explanation of which services receive profile, usage, and project data. Open code is valuable evidence, not a substitute for operating documentation.
Pricing
Reader access
$0
Public project pages, posts, and RSS feeds can be read without payment. Readers who join an update list provide their name and email to that project’s creator through kit.
Creator beta
No public price
The live page offers “Claim your kit” and still describes beta testing, but it does not publish a durable plan table. Confirm eligibility, limits, future billing, ownership, support, exports, and shutdown handling before depending on a hosted page.
Self-hosted source
MIT-licensed code
The code can be used under the MIT license. Self-hosting still requires technical labor plus accounts or replacements for authentication, database, image management, hosting, email, and any moderation or analytics services.
Readers can inspect public project pages and RSS feeds for free. Joining a creator’s list exchanges personal information for future messages, so the meaningful cost is consent and inbox attention rather than money.
The hosted creator offer does not expose a conventional public price and feature table. Before claiming a production page, ask whether beta access is free, whether limits or charges can be introduced, and how much warning accompanies a material change.
Self-hosting carries no software-license price under MIT, but the real cost includes setup, vendors, upgrades, deliverability, backups, abuse prevention, security, and support. It makes sense for a technical team that wants control, not as a shortcut to free operations.
A mature product will usually need its own domain and systems. Budget kit as an early discovery layer, then decide deliberately which content, contacts, and analytics should move to the long-term stack.
Where Keep in Touch (kit) falls behind
Publish a dated beta and roadmap page with current maintainer capacity, creator eligibility, supported features, known limitations, uptime expectations, support channel, and notice period for changes.
Add a complete hosted-service plan table covering projects, contacts, email sends, storage, bandwidth, analytics retention, custom domains, integrations, moderation, exports, support, and future pricing.
Provide kit-specific privacy documentation that maps every data field to Clerk, Turso, Cloudinary, Netlify, analytics, email, moderation, and faith.tools, including location, retention, deletion, and controller roles.
Give creators one-click exports for project content, posts, media references, leads, consent evidence, unsubscribe state, analytics, and settings in documented formats.
Document email behavior: sender identity, authentication, frequency, bounce and complaint handling, suppression, unsubscribe, privacy requests, and whether creators can upload existing lists.
Offer a supported custom-domain or canonical-link workflow so a successful page can accumulate search value without creating permanent platform lock-in.
Publish accessibility, security reporting, backup, recovery, incident response, abuse appeal, AI moderation, and account-linking documentation for the hosted service.
Show current adoption carefully: active creator pages, posting activity, subscriber delivery, directory referrals, and successful migrations without exposing private project data.
Keep in Touch vs. Carrd vs. Substack
Kit is the most specialized option: simple project pages and updates inside a Christian technology network, plus open-source code. Carrd is a mature general-purpose one-page builder with custom domains and broad design flexibility, but it does not supply a faith-tech audience or a built-in build log. Substack provides strong newsletter publishing, email delivery, discovery, and optional payments, but its publication model is heavier than a compact product-validation page.
Choose kit when relevant early feedback matters more than advanced presentation and you are comfortable with beta status. Choose Carrd when owning a polished custom-domain landing page is the priority. Choose Substack when recurring writing and email are the actual product. A sensible stack may use kit for faith.tools discovery, an owned-domain page for canonical product information, GitHub for code, and an established consent-aware email provider for the durable list.
The bottom line
Keep in Touch is a thoughtful piece of connective tissue for Christian technology, not a replacement for a product website or marketing platform. It understands that unfinished work needs a place to be seen, and it combines the right primitives: a clear page, public updates, open RSS, lightweight leads, modest analytics, and relevant faith.tools distribution. Its source code and MIT license deserve real credit. The hosted beta now needs the unglamorous trust layer around those primitives—specific pricing, exports, consent records, service boundaries, security and accessibility documentation, creator support, and a migration path. A builder should claim a page if the audience fit is strong, label the project stage honestly, publish useful progress instead of promotional fog, and keep independent copies of every essential asset. Used that way, kit can shorten the distance between a good Christian software idea and the first people able to improve it. Used as the sole home for a brand and subscriber list, it carries more platform and founder concentration than the present documentation can justify.
Alternatives to Keep in Touch (kit)
Frequently asked questions
What is Keep in Touch (kit)?
It is a faith.tools companion service for Christian builders to publish a project landing page and updates, collect email interest, expose RSS, view basic traffic, and gain directory visibility while a product is still being developed.
Is kit free?
Public pages and feeds are free to read. The creator service is described as a beta and does not publish a complete current pricing table, so prospective creators should confirm access, limits, and future billing before depending on it.
Is Keep in Touch open source?
Yes. Cameron Pak publishes the code on GitHub under the MIT license. The hosted service still depends on third-party infrastructure and operating policies that are separate from the permission to use the code.
Does kit replace a website or email platform?
Usually not. It is strongest as an early project page and discovery channel. A mature product will normally need an owned domain, durable email consent and export controls, support, documentation, analytics, and operational guarantees elsewhere.
What information does the signup form collect?
The public example asks for a name, email address, and an optional first impression, and states that signup agrees to project updates. Confirm storage, sender, frequency, unsubscribe, deletion, export, and third-party processing before using the form.
Can I self-host kit?
The MIT license allows use and modification of the public code. The README documents a stack that needs application, authentication, database, image, and deployment services, so self-hosting requires ongoing technical and privacy work.
Who is behind kit?
Kit was created by Cameron Pak, the founder of faith.tools. The live page identifies it as a faith.tools experiment and now uses shared sign-in with the directory.
Sources & further reading
More Focus, Habit & Productivity Apps
EpistleEpistle brings missionary updates, partner responses and ministry-partner-development records into one thoughtful workflow—powerful for ordinary communication, but sensitive stories, donor data and AI coaching demand much clearer boundaries than a newsletter tool alone.
The GAPPThe GAPP gives mission teams a configurable system for recording activity, groups, churches and people-group context across offline fieldwork—capable operational software whose location-rich spiritual records require a threat model before a rollout.
Disciple.ToolsDisciple.Tools is a free open-source CRM for contacts, groups, churches, coaching and movement maps that organizations can control on their own WordPress infrastructure—an unusually capable system whose freedom transfers security and governance to the operator.
GlossaGlossa sends live sermon captions and translated audio in more than 100 languages to ordinary phones, with church-specific vocabulary and optional voice cloning—but leaders must test accuracy, consent, latency, privacy and fallback plans before Sunday dependence.
AtomsAtoms turns James Clear’s Atomic Habits framework into reminders, repetitions, identity cues, lessons, and progress tracking—an elegant aid for consistent practices, but a religiously neutral tracker whose privacy disclosures and cross-platform quality need scrutiny.
Hope TranslatorLive captions and AI translation let listeners follow a sermon from any phone without installing an app—but pricing is complex and the privacy policy never explains microphone or transcript handling.