PuKaX
Senior Member
Hi mọi người, vừa rồi mình có xây dựng một cái SaaS app nho nhỏ, và có đăng tải lên một vài cộng đồng startup như indiehackers, hacker news... để xin nhận xét. Tuy nhiên thì ứng dụng của mình sử dụng UI là tiếng Việt nên cũng chưa nhận được nhiều quan tâm cũng như đóng góp ý kiến cho lắm. Mà hiện tại ở Việt Nam mình thì lại chưa có website cộng đồng nào về startup cả, nên thôi mạo muội đăng lên đây, vì dù gì voz là nơi mình tham gia đã lâu, lại có không ít cao nhân ẩn dật, hy vọng sẽ nhận được ít nhiều gạch, đá, cát, sỏi, xi măng về hoàn thiện cái dự án biệt phủ của mình.
Để tránh wall of text mình sẽ để nội dung câu chuyện trong spoiler, đại loại là mời anh em ghé thăm trải nghiệm app của mình tại https://transmoni.vn và nếu được cho mình xin chút ý kiến nhận xét, góp ý. Cảm ơn anh em đã bớt chút thời gian ghé qua thớt này, nếu có sai sót mong mod thương tình nhẹ tay đao, xin đa tạ!
Hi cả nhà, sau một ngày đăng đàn mình đã nhận được khá nhiều ý kiến đóng góp của mọi người, thật sự rất cảm ơn các bác đã bớt chút thời gian ghé thăm app của mình. Post này mình sẽ giải thích thêm về một số vấn đề mà các bác đã đặt câu hỏi như sau:
Để tránh wall of text mình sẽ để nội dung câu chuyện trong spoiler, đại loại là mời anh em ghé thăm trải nghiệm app của mình tại https://transmoni.vn và nếu được cho mình xin chút ý kiến nhận xét, góp ý. Cảm ơn anh em đã bớt chút thời gian ghé qua thớt này, nếu có sai sót mong mod thương tình nhẹ tay đao, xin đa tạ!
Chả là năm vừa rồi covid nó tung hoành ác quá, lúc đầu cũng nghĩ đâu nó đơn giản, hết đợt một tưởng rằng mọi thứ sẽ bình yên trở lại. Ai ngờ đâu, lại ra tiếp tục đợt 2 rồi đợt 3, khiến cho thời gian rảnh rỗi của mình nó tăng lên một cách mất kiểm soát. Vì vậy nên mình quyết định làm một cái gì đó để giết thời gian, cũng như đỡ ngứa tay ngứa chân và khỏi "lụt" nghề code dạo của bản thân.
Lên ý tưởng
Trong lúc vắt óc suy nghĩ xem nên làm gì thì tình cờ có một thành viên trong group lập trình mà mình tham gia có hỏi về vấn đề xin API của ngân hàng cũng như có cách nào để tích hợp chuyển khoản vào website của họ không... Thì mình chợt nhớ ra cũng đã từng rơi vào hoàn cảnh i chang xì đúc, đó là làm cách nào để khách hàng chuyển tiền vào tài khoản công ty thì sẽ tự động cộng tiền trong tài khoản của họ trên website. Lúc đó cũng bế tắc lắm vì đời nào ngân hàng họ chịu cấp API cho cá nhân hay các doanh nghiệp cỡ nhỏ lại chả dính dáng gì đến nghiệp vụ của họ! Và giải pháp cuối cùng là mình quyết định làm một cái module tự động truy xuất giao dịch trong tài khoản để áp vào website của công ty. Nhưng nó là câu chuyện của nhiều năm trước rồi, nay vô tình có người nhắc lại nên mình thử hỏi ông anh con bác Google xem có gì đổi mới chưa, một phần vì muốn trao đổi với thanh niên trên group, một phần cũng để cập nhật tin tức nữa... và thật bất ngờ nó... vẫn vậy. Điểm sáng duy nhất là bắt đầu có định nghĩa về open banking, tuy nhiên chỉ có ông OCB là gia nhập hội này, mà cũng rất hạn chế tính năng (chắc do là đơn vị tiên phong nên cũng chưa dám open quá). Thêm vào đó open banking thì mình cũng cần chủ động truy xuất thông tin chứ khó có thể nào phía ngân hàng lại chủ động gửi instant payment notification cho mình cả. Vì vậy mình quyết định lôi cái module mà mình xây dựng trước đây để làm "cái gì đó" đang trăn trở bấy lâu.
Use case
Như đã trình bày ở trên, use case cho dự án này là việc cung cấp một giải pháp để tích hợp hình thức thanh toán tự động thông qua giao dịch chuyển khoản ngân hàng. Ngoài ra thì mình còn mở rộng thêm về các hình thức thông báo giao dịch và biến động số dư thông qua các kênh nhắn tin trực tuyến như Telegram, Slack... phục vụ trong trường hợp bạn muốn chia sẻ thông tin giao dịch cho gia đình hoặc nhóm làm việc của mình nhưng lại không muốn giao tài khoản ngân hàng cho họ.
Triển khai
Ý tưởng là vậy, mặc dù cái module mình làm trước đây vẫn chạy tốt, thỉnh thoảng ngân hàng họ cập nhật hệ thống thì mình chỉ phải mô đi phê lại chút là lại ngon lành. Nhưng để làm SaaS app thì cần nhiều thứ hơn nữa. Nào là website để quản lý user, cách thức liên kết tài khoản ngân hàng, quản lý lịch trình truy xuất dữ liệu, rồi tiếp đến còn thu phí thuê bao ra sao... hầm bà lằng. Nói chung mình mất khoảng 6 tháng để mọi thứ gọi là hòm hòm, và mất thêm 3 tháng để live test, khá oải.
Trong thời gian thử nghiệm hệ thống mình có dùng free tier của Amazon aws và Google cloud, nên mình cũng dự kiến là nếu lên production cũng sẽ dùng của 2 anh này thôi. Tuy nhiên chi phí thì khá là ối giời ơi nó đắt, free tier thì không thể dùng làm production được, đến lúc "on air" thì tiền đâu ra mà trả trong thời gian đầu khi chưa có khách hàng. May mắn thay khi tìm hiểu kinh nghiệm của các startup khác thì thấy họ nhắc đến aws activate, đại loại đây là một chương trình hỗ trợ khởi nghiệp của Amazon, các startup sẽ được tài trợ một số tiền (quy ra credits) để thuê cơ sở hạ tầng của họ (chủ yếu là họ nuôi mình lúc còn non nớt, sau này lớn mạnh mình sẽ nuôi lại họ, đây là hợp tác win-win, mà kể cả mình có không dùng của họ thì cũng chả sao, tây nó thoáng). Thấy cũng ngon, nên cũng liều đăng ký thử, và sau vài vòng ép cung, họ đồng ý cấp cho mình 1000 USD sử dụng cho cơ sở hạ tầng và 350 USD cho hỗ trợ kỹ thuật, toẹt vời ông mặt trời.
Và đến giờ phút này thì "nó" đã thực sự hoàn thiện rồi, mặc dù còn nhiều tính năng mà mình muốn phát triển thêm nữa nhưng những gì trong ý tưởng của mình đã hoàn thành, giờ thì chờ xem thiên hạ đón nhận nó ra sao mà thôi.
Lên ý tưởng
Trong lúc vắt óc suy nghĩ xem nên làm gì thì tình cờ có một thành viên trong group lập trình mà mình tham gia có hỏi về vấn đề xin API của ngân hàng cũng như có cách nào để tích hợp chuyển khoản vào website của họ không... Thì mình chợt nhớ ra cũng đã từng rơi vào hoàn cảnh i chang xì đúc, đó là làm cách nào để khách hàng chuyển tiền vào tài khoản công ty thì sẽ tự động cộng tiền trong tài khoản của họ trên website. Lúc đó cũng bế tắc lắm vì đời nào ngân hàng họ chịu cấp API cho cá nhân hay các doanh nghiệp cỡ nhỏ lại chả dính dáng gì đến nghiệp vụ của họ! Và giải pháp cuối cùng là mình quyết định làm một cái module tự động truy xuất giao dịch trong tài khoản để áp vào website của công ty. Nhưng nó là câu chuyện của nhiều năm trước rồi, nay vô tình có người nhắc lại nên mình thử hỏi ông anh con bác Google xem có gì đổi mới chưa, một phần vì muốn trao đổi với thanh niên trên group, một phần cũng để cập nhật tin tức nữa... và thật bất ngờ nó... vẫn vậy. Điểm sáng duy nhất là bắt đầu có định nghĩa về open banking, tuy nhiên chỉ có ông OCB là gia nhập hội này, mà cũng rất hạn chế tính năng (chắc do là đơn vị tiên phong nên cũng chưa dám open quá). Thêm vào đó open banking thì mình cũng cần chủ động truy xuất thông tin chứ khó có thể nào phía ngân hàng lại chủ động gửi instant payment notification cho mình cả. Vì vậy mình quyết định lôi cái module mà mình xây dựng trước đây để làm "cái gì đó" đang trăn trở bấy lâu.
Use case
Như đã trình bày ở trên, use case cho dự án này là việc cung cấp một giải pháp để tích hợp hình thức thanh toán tự động thông qua giao dịch chuyển khoản ngân hàng. Ngoài ra thì mình còn mở rộng thêm về các hình thức thông báo giao dịch và biến động số dư thông qua các kênh nhắn tin trực tuyến như Telegram, Slack... phục vụ trong trường hợp bạn muốn chia sẻ thông tin giao dịch cho gia đình hoặc nhóm làm việc của mình nhưng lại không muốn giao tài khoản ngân hàng cho họ.
Triển khai
Ý tưởng là vậy, mặc dù cái module mình làm trước đây vẫn chạy tốt, thỉnh thoảng ngân hàng họ cập nhật hệ thống thì mình chỉ phải mô đi phê lại chút là lại ngon lành. Nhưng để làm SaaS app thì cần nhiều thứ hơn nữa. Nào là website để quản lý user, cách thức liên kết tài khoản ngân hàng, quản lý lịch trình truy xuất dữ liệu, rồi tiếp đến còn thu phí thuê bao ra sao... hầm bà lằng. Nói chung mình mất khoảng 6 tháng để mọi thứ gọi là hòm hòm, và mất thêm 3 tháng để live test, khá oải.
Trong thời gian thử nghiệm hệ thống mình có dùng free tier của Amazon aws và Google cloud, nên mình cũng dự kiến là nếu lên production cũng sẽ dùng của 2 anh này thôi. Tuy nhiên chi phí thì khá là ối giời ơi nó đắt, free tier thì không thể dùng làm production được, đến lúc "on air" thì tiền đâu ra mà trả trong thời gian đầu khi chưa có khách hàng. May mắn thay khi tìm hiểu kinh nghiệm của các startup khác thì thấy họ nhắc đến aws activate, đại loại đây là một chương trình hỗ trợ khởi nghiệp của Amazon, các startup sẽ được tài trợ một số tiền (quy ra credits) để thuê cơ sở hạ tầng của họ (chủ yếu là họ nuôi mình lúc còn non nớt, sau này lớn mạnh mình sẽ nuôi lại họ, đây là hợp tác win-win, mà kể cả mình có không dùng của họ thì cũng chả sao, tây nó thoáng). Thấy cũng ngon, nên cũng liều đăng ký thử, và sau vài vòng ép cung, họ đồng ý cấp cho mình 1000 USD sử dụng cho cơ sở hạ tầng và 350 USD cho hỗ trợ kỹ thuật, toẹt vời ông mặt trời.
Và đến giờ phút này thì "nó" đã thực sự hoàn thiện rồi, mặc dù còn nhiều tính năng mà mình muốn phát triển thêm nữa nhưng những gì trong ý tưởng của mình đã hoàn thành, giờ thì chờ xem thiên hạ đón nhận nó ra sao mà thôi.
Hi cả nhà, sau một ngày đăng đàn mình đã nhận được khá nhiều ý kiến đóng góp của mọi người, thật sự rất cảm ơn các bác đã bớt chút thời gian ghé thăm app của mình. Post này mình sẽ giải thích thêm về một số vấn đề mà các bác đã đặt câu hỏi như sau:
Vấn đề use case
Lấy ví dụ với số lượng giao dịch như trong ảnh mình đính kèm dưới đây, nó quá nhiều các bác ạ. Và với số lượng lớn như vậy sẽ đến lúc các bác cần nhân lực riêng chỉ để phục vụ cho việc đối chiếu giao dịch. Trong trường hợp của mình trước đây thì không chỉ 1, mà đến 3 người để làm việc này. Tuy nhiên sức người có hạn, nhân sự của các bác làm việc tối đa cũng chỉ 8-10 tiếng 1 ngày mà thôi, thêm nữa họ còn nghỉ cuối tuần, nghỉ lễ... còn khách hàng thì không, họ có thể thực hiện giao dịch bất cứ lúc nào họ cần, kể cả nửa đêm. Vậy trong trường hợp không có nhân lực đối chiếu giao dịch, khách hàng sẽ phải chờ đến giờ làm việc, cuối tuần hoặc nghỉ lễ thì phải chờ đến ngày làm việc tiếp theo => mất khách.
View attachment 374010
Thật sự mà nói thì mình làm app này không phải theo kiểu cọc đi tìm trâu, mà nhu cầu là hiện hữu, vì trong mô hình kinh doanh chính mà mình đang vận hành nó có những vấn đề phát sinh cần đến giải pháp này. Nghĩa là nhu cầu có rồi, mình chỉ là người cung cấp giải pháp mà thôi.
Vấn đề bảo mật
Mình sẽ giải thích thêm về việc bảo mật thông tin tài khoản của khách hàng bằng hình ảnh dưới đây.
View attachment 374011
Chú giải như sau:
Lấy ví dụ với số lượng giao dịch như trong ảnh mình đính kèm dưới đây, nó quá nhiều các bác ạ. Và với số lượng lớn như vậy sẽ đến lúc các bác cần nhân lực riêng chỉ để phục vụ cho việc đối chiếu giao dịch. Trong trường hợp của mình trước đây thì không chỉ 1, mà đến 3 người để làm việc này. Tuy nhiên sức người có hạn, nhân sự của các bác làm việc tối đa cũng chỉ 8-10 tiếng 1 ngày mà thôi, thêm nữa họ còn nghỉ cuối tuần, nghỉ lễ... còn khách hàng thì không, họ có thể thực hiện giao dịch bất cứ lúc nào họ cần, kể cả nửa đêm. Vậy trong trường hợp không có nhân lực đối chiếu giao dịch, khách hàng sẽ phải chờ đến giờ làm việc, cuối tuần hoặc nghỉ lễ thì phải chờ đến ngày làm việc tiếp theo => mất khách.
View attachment 374010
Thật sự mà nói thì mình làm app này không phải theo kiểu cọc đi tìm trâu, mà nhu cầu là hiện hữu, vì trong mô hình kinh doanh chính mà mình đang vận hành nó có những vấn đề phát sinh cần đến giải pháp này. Nghĩa là nhu cầu có rồi, mình chỉ là người cung cấp giải pháp mà thôi.
Vấn đề bảo mật
Mình sẽ giải thích thêm về việc bảo mật thông tin tài khoản của khách hàng bằng hình ảnh dưới đây.
View attachment 374011
Chú giải như sau:
- Web service: là service sẽ tương tác trực tiếp với người dùng, như đăng ký hay quản lý subscription. Sau khi người dùng liên kết tài khoản, service này sẽ ngay lập tức mã hóa toàn bộ thông tin bằng RSA public key (4096 bits), sau đó gửi lên SQS-A (sử dụng mã hóa AES-256 bits). Web service chỉ có quyền PUB lên SQS-A mà không có quyền SUB để gọi ngược thông tin trên SQS-A về.
- Crawler service: là service tương tác với phía ngân hàng, nó có quyền SUB vào SQS-A để nhận thông tin tài khoản web service gửi lên, và sử dụng RSA private key để giải mã thông tin đó (web service không có private key này). Sau khi truy xuất thông tin giao dịch nó sẽ gửi thông tin theo SQS-B, nơi nó có quyền PUB nhưng quyền SUB lại chỉ có ở web service mà thôi.
Last edited:
. Đùa thôi mình chủ yếu chơi twitter, mà cũng không đăng status mấy, chủ yếu follow mấy lão developer để đọc thôi.
