[TriLUG] release format for commercial project

[Wes Garrison via TriLUG]

That is definitely the biggest question.

Our plan is to develop an easy database export file that you can share with
your accountant, which will take whatever changes they make and give you a
"diff" of sorts to import into your local software.

We will probably offer our software to accountants for free for preparing
their clients' taxes, but they will need to buy a license if they are
keeping books for their clients.

For a small shop, this shouldn't be a problem, but for larger firms they
will probably need bulk pricing.

We're going to get our MVP* out their first and see what people think, but
we're talking to accountants to get their input too.

We have to make it easy for people to work with their accountants or no one
will be "able" to switch.

*MVP is entrepreneur-speak for "Minimum Viable Product"

On Fri, Sep 18, 2026 at 11:52 AM Aaron Thomas via TriLUG <trilug at trilug.org>
wrote:

> Sounds like a fantastic product.
>
> Biggest question is how will my accountant get the files and will it be
> easy for her to transition
>
> On 9/18/26 11:09 AM, Wes Garrison via TriLUG wrote:
> > Thanks Bill and Stephen for the great feedback.
> >
> > I built an AppImage and it actually works great with our embedded
> database
> > right out of the box, so I was misinformed.
> >
> > It actually worked better with our build system than Flatpak, so we may
> > favor AppImage instead.  I'd still like to support Flatpak for those who
> > want it, as that will let us distribute on Flathub and hopefully help us
> > find an audience, but it's not our top priority.
> >
> > We're using Postgres because we're going to offer users the option to
> host
> > on their local network in addition to just locally on their PC, and we'd
> > like to use the same DB if possible.
> >
> > We're hoping we will find an audience of folks who hate the new "you will
> > own nothing" paradigm, and want to purchase software once and use it as
> > long as it suits their needs.
> >
> > Now that QuickBooks is no longer offering a desktop version at all, that
> > gives us an opportunity to grab some of those customers.
> >
> > We're calling our product "FQB", for "First Quality Books" obviously.
> >
> > Here's our IndieGoGo campaign if anyone is interested in following us:
> > https://www.indiegogo.com/en/projects/fqb-accounting/first-quality-books
> >
> > ...and we have dark mode :)
> >
> > Thanks again for the feedback,
> >
> > -Wes
> >
> > On Thu, Sep 17, 2026 at 7:34 AM Stephen Wiley <swiley at swiley.net> wrote:
> >
> >> I've always preferred AppImage to Flatpak even when I was running Alpine
> >> (I think I typically ran them in a chroot.)
> >>
> >> Is there a reason you went with Postgress instead of Sqlite? That's kind
> >> of an intense RDBMS to be embedding.
> >>
> >> --Stephen
> >>
> >> On Wed, Sep 16, 2026 at 10:42:44PM -0400, Wes Garrison via TriLUG wrote:
> >>> Hey folks,
> >>>
> >>> We're about ready to release testing versions of our Business
> Bookkeeping
> >>> product to compete with QuickBooks.
> >>>
> >>> Currently I'm building a .deb, .rpm, and .pacman. (x64/amd64 only, no
> >> arm64
> >>> yet for win or linux, but the macOS build supports arm64 and Intel)
> >>>
> >>> Flatpak works, but building it is a clunky process.  Everything seems
> to
> >>> install and work if you install it for the system, but the icon doesn't
> >>> show up, and installing it with `flatpak --user` is confusing.
> >>>
> >>> How important is flatpak to people?  We probably won't release to
> Flathub
> >>> even if we build a flatpak.
> >>>
> >>> I don't really want to do Snap, and appimage doesn't seem right for our
> >> use
> >>> case, since we are using an embedded Postgresql database, but I'm
> willing
> >>> to be convinced otherwise.
> >>>
> >>> Building for Alpine seems like a huge pain, and it's a small user base,
> >>> even by Linux standards.
> >>>
> >>> How much effort should I put into flatpak, and should I be considering
> >>> other options besides the 3 I mentioned?
> >>>
> >>> Thanks!
> >>>
> >>> -Wes
> >>> --
> >>> This message was sent to: Stephen Wiley <swiley at swiley.net>
> >>> To unsubscribe, send a blank message to trilug-leave at trilug.org from
> >> that address.
> >>> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
> >>> Unsubscribe or edit options on the web        :
> >> https://www.trilug.org/mailman/options/trilug/swiley%40swiley.net
> >>> Welcome to TriLUG: https://trilug.org/welcome
> >>
> --
> This message was sent to: Wes <wes at xitechusa.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> address.
> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  :
> https://www.trilug.org/mailman/options/trilug/wes%40xitechusa.com
> Welcome to TriLUG: https://trilug.org/welcome